Read on Twitter
(1/N)
Code coverage: when most of your code is covered by #tests.
Percentage?
80% is fair enough
90% is better
100% is ideal but almost impossible
Ok, but why should we care about code coverage?
Code coverage: when most of your code is covered by #tests.
Percentage?
80% is fair enough
90% is better
100% is ideal but almost impossible
Ok, but why should we care about code coverage?
(2/N)
High coverage means that almost all the lines of code are executed AT LEAST ONCE.
We need to test all the possible branches (if-else, switch, try-catch-finally) to ensure that our system behaves correctly.
Remember to test also what happens in the catch and finally blocks!
High coverage means that almost all the lines of code are executed AT LEAST ONCE.
We need to test all the possible branches (if-else, switch, try-catch-finally) to ensure that our system behaves correctly.
Remember to test also what happens in the catch and finally blocks!
(3/N)
The more your code is covered by tests, the more you can be sure not to introduce regressions.
But to avoid regressions you can't only rely on unit tests, but must write some integration tests.
How many? Well, it depends on your project.
The more your code is covered by tests, the more you can be sure not to introduce regressions.
But to avoid regressions you can't only rely on unit tests, but must write some integration tests.
How many? Well, it depends on your project.
(4/N)
BTW you must not cheat! Write only meaningful tests. So, don't test only the happy paths, but test for all the worst situations.
- Invalid input
- Inner exceptions
- Null references
Only this way you can provide meaningful tests and be sure you haven't wasted your time
BTW you must not cheat! Write only meaningful tests. So, don't test only the happy paths, but test for all the worst situations.
- Invalid input
- Inner exceptions
- Null references
Only this way you can provide meaningful tests and be sure you haven't wasted your time
(5/N)
When I say "meaningful tests", I mean that you should not test your POCO classes, since those tests don't provide value.
You don't have to test that the Get returns the same value provided by the Set, if you're not doing some other calculations.
When I say "meaningful tests", I mean that you should not test your POCO classes, since those tests don't provide value.
You don't have to test that the Get returns the same value provided by the Set, if you're not doing some other calculations.
(6/N)
If you are using #csharp, decorate your POCO classes with the [ExcludeFromCodeCoverage] attribute.
If you are using #csharp, decorate your POCO classes with the [ExcludeFromCodeCoverage] attribute.
(7/N)
How to understand when your tests DO NOT cover enough code?
1. Add some breaking changes (like update some algorithm, change the format of a string...)
2. Run your tests
If all tests pass, you haven't covered your code with enough tests
How to understand when your tests DO NOT cover enough code?
1. Add some breaking changes (like update some algorithm, change the format of a string...)
2. Run your tests
If all tests pass, you haven't covered your code with enough tests
(8/N)
How NOT to fix your tests?
1. Run your failing tests
2. Copy the "actual" result and copy it in the "expected" result.
You are not fixing your code, you are fixing your tests.
Use your brain when writing tests.
How NOT to fix your tests?
1. Run your failing tests
2. Copy the "actual" result and copy it in the "expected" result.
You are not fixing your code, you are fixing your tests.
Use your brain when writing tests.
(9/N)
Don't write tests bc everyone says that you must write them.
Write tests bc they will save your ass when something unexpected happens, or when you need to add some more features that may impact your existing code.
Be smart
Don't write tests bc everyone says that you must write them.
Write tests bc they will save your ass when something unexpected happens, or when you need to add some more features that may impact your existing code.
Be smart
