Antichesse (o ^ω^ o)
Un framework de test de mutation pour JRE, donc qui marche avec Kotlin et Java.
Je viens de percuter qu'en Rust, les TU sont dans le même fichier que celui du source à tester à ceci près qu'ils sont dans un module appelé tests... J'ai failli vomir sur le coup !
On a quand même bientôt 20 années de Maven et Gradle, ou de Composer et Symfony, ou encore presque une décennie de npm/yarn et Karma, de rake et Ruby, de pyb et Python ; et des gens n'ont toujours pas compris qu'il y avait une différence entre les sources qu'on livre et celles qui servent à fabriquer les sources qui vont être livrées. De la même manière qu'il ne faut pas générer les binaires dans le répertoire ./src il ne faut pas mélanger le code de ses TU avec celui de son programme, idem pour les ressources des tests et du programme.
Il n'y a pas à dire, l'univers des langages bas niveau (C/C++/Rust/Go/etc) est d'une pauvreté en terme de méthodologie, c'est incroyable ! D'autant qu'une bonne partie des personnes y œuvrant se prends systématiquement pour des cadors, j'ai de la peine pour eux et encore plus pour ceux qui doivent faire avec...
Bref, pour des raisons évidentes d'hygiène je vais détourner le répertoire des TI en TU si c'est possible de le faire...
EDIT : l'arborescence standard d'un projet Rust.
.
├── Cargo.lock
├── Cargo.toml
├── src/
│ ├── lib.rs
│ ├── main.rs
│ └── bin/
│ ├── named-executable.rs
│ ├── another-executable.rs
│ └── multi-file-executable/
│ ├── main.rs
│ └── some_module.rs
├── benches/
│ ├── large-input.rs
│ └── multi-file-bench/
│ ├── main.rs
│ └── bench_module.rs
├── examples/
│ ├── simple.rs
│ └── multi-file-example/
│ ├── main.rs
│ └── ex_module.rs
└── tests/
├── some-integration-tests.rs
└── multi-file-test/
├── main.rs
└── test_module.rsJe viens de tester chez Free et Free Mobile => les deux sont 100 % ok.
@Chlouchloutte t'es pas chez Orange ou Sosh pour nous dire ?
Pour tester des SPA avec Firefox, Chrome, etc
Un outil permettant d'exécuter un test de charge sans trop d'effort, en décrivant les tests à poursuivre via une syntaxe proche de JUnit et qui fourni de super graphiques en plus !
J'aime beaucoup ! Je pense à toi @Animal pour que transmette ça à Sigmund :-)
Via ChezSoi
Je cite :
il n’ y a pas eu de phase de tests de régression dédiée et que les tests non fonctionnels ont été conduits sur une période de temps inadéquate parce que très courte.
Et puis je rigole. Comme d'hab quoi, les tests c'est pour les looser, nous on en finance, on est des winner et là... On a tout gagné... Double-lol !
À mettre à côté de siege ! Bien pratique.
Mon client m'a demandé de lui faire part de différents frameworks de test End-to-End qui marcheraient bien avec des SPA. Ici Nightwatch dont le seul défaut est de ne pas gérer nativement le Gherkin (même s'il est possible de lui greffer une bidouille).
Un exemple :
Je résume, si vos tests unitaires sont deux à deux distincts, s'ils n'engendre pas de conflits lors de leur exécution en parallèle (donc il faut dissocier les TU des TI qui quant à eux s'appuient sur l'injection de dépendances) alors vous pouvez dire à Surefire d'exécuter en parallèle autant de TEST que vous avez de Thread CPU de disponibles.
Après un benchmark succinct, j'ai divisé par 5 le temps d'exécution de mes tests sur un 4 cœurs physiques et 8 cœurs logiques via la technologique HT (Hyper-Threading chez Intel / Hyper-Transport chez AMD).
Voici comment faire :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M3</version>
<configuration>
<forkCount>1C</forkCount> <!-- C'est la même commande que pour Maven, 1 thread / CPU -->
<reuseForks>true</reuseForks>
</plugin>Je découvre l'outil grâce à Kalvn (qui tient toujours sa place parmi mes 3 shaarlistes préférés <3).
Et voici un tuto que propose Kalvn sur Artillery.
Je réponds à ton post Lenny. En cherchant un peu je suis tombée sur un soft de benchmark en ligne de commande qui s'utilise hyper simplement : Siege.
Comment est-ce qu'il s'installe :
sudo apt install siegeVoici quelques exemples pour t'aider avec AC.
# Lancer un benchmark pendant 60 sec
siege -b -t60S http://www.cakeozolives.com/shaarli-antichesse/
# Lancer 50 clients requêtant entre 0 et 10 sec pendant 1 minute
siege -c50 -d10 -t1M http://www.cakeozolives.com/shaarli-antichesse/
# Faire pareil mais en requêtant plusieurs URL
siege -c50 -d10 -i -f site.txtPar exemple avec mon Shaarli :
$ siege -b -t60S http://www.cakeozolives.com/shaarli-antichesse/
** SIEGE 4.0.4
** Preparing 25 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions: 1881 hits
Availability: 100.00 %
Elapsed time: 59.22 secs
Data transferred: 20.38 MB
Response time: 0.75 secs
Transaction rate: 31.76 trans/sec
Throughput: 0.34 MB/sec
Concurrency: 23.77
Successful transactions: 1881
Failed transactions: 0
Longest transaction: 9.89
Shortest transaction: 0.06
Et si on pouvait rendre les tests plus simples à écrire et à lire, aussi simple qu’un assert, mais un résultat plus clair que unittest en sortie ?
C'est vrai que les TU avec Pytest sont concis et élégants. Un bon tuto !
“Tap compare” is a testing technique that allows you to test the behavior and performance of the new service by comparing its results against the old service. This article provides an example of using a new open source tool, Diferencia, and mirroring production traffic across both old and new services to compare the difference in result.
Des outils et techniques pour tester la non-régression des contrats d'interfaçage entre micro-services.
Excellent !
Riduildel, cher ami, ce qui est décrit dans l'article ne constitue pas des tests unitaires dans le sens où ils sont covariants au code alors qu'un test unitaire, écrit en TDD est par essence contravariant.
Dit autrement, un test unitaire n'a pas besoin d'être modifié lorsque le code change puisqu'il est découplé du code. Pour le dire autrement, cela fait plus de 10 ans que j'écris des tests unitaires et je n'ai réellement compris ce qu'il fallait faire et comment en écrire que depuis moins d'un an... #Craftsmanship
Gotcha !!!
Je recherchais depuis hier un article exposant clairement la différence entre des tests unitaires et des tests en TDD.
C'est plus clair à présent
Je m'étais déjà faite la remarque : quand je refactor mon code, je casse toujours mes tests et je recolle les bouts à la fin.
Mes TU sont donc fortement couplés à mon code et ça c'est moisi.
Lu en commentaire d'un post sur internet :
Je n'ai pas peur de l'ordinateur qui réussira le test de Turing. Non, ce qui me terrifie, c'est celui qui y échouera intentionnellement.
Un outil de test de charge en Python. À essayer chez les clients.
Un framework de test pour ses scripts Bash : shunit2