TDD: Document Unit Tests and automated UI Testing
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Documentation
- Clarté
- À clarifier
- Activité
- À l'abandon
- Domaine
- documentation, testing
Piste de recherche
Commencez par examiner l’infrastructure Gtk.test_init indiquée, Vest, Valadate, GNOME Wiki TestSample et les références Gherkin. Déterminez et documentez les approches privilégiées du projet pour les tests unitaires et les tests d’UI automatisés, en fournissant suffisamment d’indications pour que les développeurs puissent les appliquer. Le travail sera considéré comme terminé lorsque la documentation expliquera clairement les deux workflows et ne laissera pas le choix du framework indéterminé.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Problem
Currently we are not using automated testing a lot - I think this is mainly due to lack of knowledge. There's probably quite some potential in avoiding regressions, especially when we use a combination of automated UI and Unit testing.
Proposal
Document the preferred way of doing UI testing as well as Unit Testing
Prior Art (Optional)
- Gtk provides infrastructure for automated UI testing, not sure how this works though: https://valadoc.org/gtk4/Gtk.test_init.html
- There is Vest, a Unit Testing framework built with Vala: https://github.com/jorchube/vest
- There is Valadate as well which looks quite feature complete, even though it seems no longer to be maintained: https://github.com/chebizarro/valadate
- There is some documentation about testing in the GNOME Wiki (probably the foundation of Vest): https://wiki.gnome.org/Projects/Vala/TestSample
- And there is Gherkin - not sure if that's usefull in our case though: https://gist.github.com/chebizarro/6c949fafe1e9a2c59b26
- Langage dominant
- Aucune donnée de langage
- Étoiles
- 88
- Forks
- 30
- Merge moyen
- 1 j 9 h
- PR mergées (30 j)
- 1
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de elementary/docs
-
Good First Issue
Difficulté 1/5 1-3 heures Accessibilité débutants 78/100
elementary/docs#244 ·
-
Update for Sysupdate imagesOuverte
Difficulté 3/5 1-2 jours Accessibilité débutants 62/100
elementary/docs#245 ·
-
Priority: Wishlist
Difficulté 1/5 Moins d'une heure Accessibilité débutants 52/100
elementary/docs#241 · 1 réaction ·
-
Modernize design guidelinesOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 38/100
elementary/docs#236 · 3 commentaires ·
-
Needs Design Priority: Wishlist
Difficulté 2/5 1-3 heures Accessibilité débutants 48/100
elementary/docs#235 · 4 commentaires ·
Toutes les issues de elementary/docs
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 71/100
Cocoanetics/Loupe#8 ·
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 74/100
-
integration:coding-agents
Difficulté 1/5 Moins d'une heure Accessibilité débutants 83/100
vectorize-io/hindsight#6151 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
FormalLanguageConstrainedPathQuerying/FLPQ_Data#174 ·
Les mainteneurs répondent en général sous 1 jour
-
P3 provider/openrouter type/docs
Difficulté 1/5 1-3 heures Accessibilité débutants 88/100
NousResearch/hermes-agent#145909 ·
Les mainteneurs répondent en général sous 1 jour