Timeline for Efficiency of improving testability versus adding unit tests
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 2 at 11:45 | comment | added | Arseni Mourzenko | @Dnomyar96: static analysis finds all the calls to the method. The next step is to check the coverage to see whether the branch where every call is made is actually tested. While it doesn't give 100% guarantee (for instance it won't catch a case where the method is called through Reflection), it handles well the “ordinary” cases. | |
| Jun 2 at 8:45 | comment | added | Dnomyar96 | @ArseniMourzenko But how does that prevent future mistakes? If somebody calls that method from a new place, there might not be a test there that ensures its called with UTC times. I don't see how that prevents mistakes, or do you have some automated piece of code that makes sure all callers have a test for that? | |
| May 31 at 15:32 | comment | added | Arseni Mourzenko | @Heinzi: indeed, it's not the most straightforward thing to do. One way a colleague did it recently for a .NET project is through a mix of static analysis (like in SonarQube) and processing of code coverage, to ensure that all the calls to the method were tested. | |
| May 31 at 10:02 | comment | added | Heinzi |
Your second example makes perfect sense, but I don't really get your first example. How would you "do a unit test that checks all the calls to ProcessRange" (in a practical, maintainable way)?
|
|
| May 30 at 19:35 | history | answered | Arseni Mourzenko | CC BY-SA 4.0 |