L'approche de tests par propriétés est une alternative aux techniques de tests basés sur des exemples.
Cette approche est conçue pour tester les aspects d'une propriété qui doit toujours être vraie. Ceci permet de couvrir un grand éventail de valeurs d'entrées programmatiquement et de tester celles-ci en un seul test. Contrairement aux tests basés sur des exemples où l'on doit faire un test pour chaque exemple.
Nous couvrirons les outils requis pour débuter à utiliser les tests par propriété.
Nous construirons ensemble une suite de tests afin de démontrer la puissance de cette approche dans un cas réel.
2. Having over 10 years of experience with
Microsoft Technologies, Miguel has many
specializations, including C#, F#, Azure, and
DevOps practices.
MSDEVMTL co-organizer
Director of engineering at Nexus Innovations
https://blog.miguelbernard.com
https://www.linkedin.com/in/miguelbernard/
@MiguelBernard88
https://github.com/mbernard
17. Problems with example-based tests (EBT)
DON’T SCALE DON’T HELP YOU TO
FIND EDGE CASES
BRITTLE
DON’T EXPLAIN
WHAT WAS THE
REQUIREMENT
OFTEN SPECIFIC TO
AN
IMPLEMENTATION
35. PBTs advantages
General, and thus are less brittle
Provide a better and more concise description of requirements than a bunch of examples
1 PBT can replace many, many, example-based tests
Reveal overlooked edge cases
Force you to think
Ensure deep understanding of requirements
More thinking = less typing
Force you to have a clean design
63. [Property(Arbitrary = new[] { typeof(LetterGenerator) })]
public Property RowsContainCorrectLetterInCorrectOrder
(char c)
{
var expected = new List<char>();
for (var i = 'A'; i < c; i++) expected.Add(i);
for (var i = c; i >= 'A'; i--) expected.Add(i);
var actual = Diamond.Generate(c).ToList()
.Select(GetCharInRow);
return actual.SequenceEqual(expected).ToProperty();
}
64. Recap
Few simple tests (10 tests, ~4-5 lines / test)
No need to change the tests when changing the implementation
Makes it easier to do TDD
Trop d’exemples à construire pour bien couvrir
Integration des features = multiplication des paths possible
How many tests would you have to write to exhaustively prove that these two classes both work correctly under all supported configurations? “More than a human can feasibly write” is the correct answer. Now imagine having to do this for three, four, or dozens of features all working together simultaneously. You simply can’t write manual tests to cover all of the scenarios that might occur in the real world. It’s not feasible.
Trop vite
By generating random input, property-based tests often reveal issues that you have overlooked, such as dealing with nulls, missing data, divide by zero, negative numbers, etc.
more thinking, less typing