Antichesse (o ^ω^ o)
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
Un plugin Maven pour exécuter les tests unitaires à chaque changement et recompiler les classes aussi. Cela permet à Maven de rattraper un peu Gradle sur ce sujet et de proposer ce qu'il est possible de faire en JS.
Ici, le tuto compare les performances de StringBuffer et StringBuilder avec JMH
Un très bon article qui compare les systèmes de preuve formelle vs les TU et les langages fonctionnels et orientés objets.
Je mets ici les liens vers les benchmarks des différents frameworks en JS :
Un tuto pour Chlouchoutte sur les tests d'intégration avec Maven
Un tuto sur Spring-test. Il faut en lire plus souvent des comme celui-là.
Je me suis amusée à tester Fukol et son système de grille. J'aime beaucoup l'idée qu'à l'intérieur d'un div flagger avec fukol, tous les autres div devient des cellules.
C'est simple, ça mange 160 fois moins d'espace que bootstrap & Co et c'est facile.
Les deux liens vers mes deux tests :