Antichesse (o ^ω^ o)
Problème
Vous développez un plugin Maven qui doit valider des trucs sur vos projets. Dans certains cas le plugin doit planter le build, dans d'autres cas, le plugin ne fait pas planter le build.
Ce plugin sert au premier cas, car la présence d'erreur arrête le build, dans ce cas, une erreur souhaitée lors d'un test ne fait plus planter le build :
<plugin>
<groupId>com.soebes.itf.jupiter.extension</groupId>
<artifactId>itf-maven-plugin</artifactId>
<version>0.13.1</version>
</plugin>Merci à @Philou pour le lien (ça faisait longtemps) !
Au dernier trimestre 2022, voici les versions stables des navigateurs que j'utilise pour mes tests Cucumber/Selenium chez mes clients sous Windows :
-
Firefox ESR en version 102.3.0 et le GeckoDriver en version 0.31.0 pour win64.
-
Ungoogled Chromium en version 105.0.5195.127-1 et le ChromeDriver en version 105.0.5195.52 pour win32.
Le problème est qu'il s'agit là d'une moyenne.
Par exemple sur 1000 citoyens si :
- 999 personnes touchent 1000 € / mois
- 1 personne touche 1 000 000 € / mois
Alors le salaire moyen est de 1 999 € par mois...
Donc je veux bien la même info mais en retirant les 1 % les plus riches, vous savez ceux qui ont des résidences dans chaque régions et chaque pays (avec de graaaaaaandes baies vitrées), ceux qui possèdent des yachts, des jet privés, plusieurs véhicules de collections, des voitures hyper-sportives dans les 450 chevaux et qui consomment du 25/30L au 100 Km, ceux qui vont dans de grands restaurants tous les jours, ceux qui ne portent que de la haute couture et donc ne connaissent pas le contact avec des vêtements vieux ou usés...
J'aimerais bien aussi la même info en séparant les citoyens des entreprises qui polluent sans restriction en violant les normes environnementales sans aucun scrupule car pas de contrôle ni de peine vraiment contraignante...
La pollution n'est pas une affaire de responsabilité individuelle, c'est une affaire publique, à la seule responsabilité du politique. Or le politique et l'hyper-bourgeoisie se confondent, tout l'enjeu pour nos dirigeants est donc de se déresponsabiliser et de se défausser à grand coup de propos moralistes auprès de la population.
Du reste le test était fun, j'ai fait 4,1 T / an voilà.
Comment tester du Kafka via des TU.
Si vous codez en procédurale (et non en objets) vous employez probablement un anti-pattern qui s'appelle getter/setter, votre code est globalement séparé en de bonnes grosses couches techniques et ajouter une fonctionnalité consiste à ajouter sempiternellement le même type de code sur toutes les couches. #Boring
Subséquemment, vous avez probablement d'énormes grappes de structures de données que vous avez besoin de comparer récursivement durant vos tests.
Heureusement pour vous AssertJ est là et vous évitera d'avoir à coder proprement :
assertThat(actualObject)
.usingRecursiveComparison()
.isEqualTo(expectedObject);Désolé pour le ton, mais c'est lourdingue de voir des ingénieurs proclamés "experts" qui au bout de 15/20 ans de métier ne font toujours pas la différence entre les paradigmes procédurale et objets. #Affligeant
Problème
HSQLDB ou H2DB sont deux super beaux projets ! En substance, ils permettent, durant les phases de tests, de charger des BDD en mémoire et d'utiliser le dialecte de la base que l'on aura en production (eg. PostgreSQL, Oracle, etc).
Sauf que les dialectes des BDD changent et que toutes les syntaxes ne sont pas complétement implémentées...
Solution
Les TestContainers ! C'est-à-dire que pour charger votre BDD durant vos tests, vous aller écrire ceci :
public class MyTest {
private static DataSource dataSource;
private static MySQLContainer mysql;
@BeforeClass
public static void init() throws InterruptedException{
//You can also use the GenericContainer for arbitrary containers
//But there are convenient classes for common databases.
mysql = new MySQLContainer("mysql:5.5.53");
mysql.start();
dataSource = DataSourceBuilder.create()
.url(mysql.getJdbcUrl())
.username(mysql.getUsername())
.password(mysql.getPassword())
.driverClassName("com.mysql.cj.jdbc.Driver")
.build();
}
@AfterClass
public static void destroy(){
mysql.close();
}
@Test
public void foo(){
//use the database
}
}Le seul prérequis, avoir podman (oui car Docker c'est has been).
Enjoy :D
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.