Code normally works fine after you write it and then hopefully at least test by hand. The new guy 5 years later, which do not fully grasp the extent of his actions, and the guy reviewing the code also not being too familiar with it, will not make sure everything does as intended.
Tests are correctness guarantees, and requires the code and/or the test to change to pass. They also explain how something should behave to people that don’t know. I work in a area where there are so many businesses rules that there is no one person that knows all of it, and capturing the rules as tests is a great way to make sure that rules remains true after someone else comes to change the code.
This might work when the test really describes&tests the business rule, not when the test simply contains a mirror of the implementation with everything replaced by mocks and just checks that the implementation is what it is, conditioning all people changing the code in the future to always have to change the test as well.
Tests can be messed up just like anything else can be messed up. Doesn’t mean that the concept itself is flawed.
If you only do things that people cannot mess up, then you’ll quickly end up not doing anything at all.
The biggest benefit to me that testing has is when refactoring. If I have decent test coverage and I change something major, tests help me to see if I accidentally broke something on the way, which is especially helpful if I am touching ancient code written by someone who left the company years ago.
Blech, this is my least favorite kind of testing. I’d much rather have some all-encompassing integration tests even if they’re confusing AF, than the “yep the language still works as advertised” nonsense that this approach often amounts to.
Capturing the rules as documentation (especially external documentation like confluence) is a great way to make sure nobody ever reads it. Or even finds it.
Yeah, good luck reading 20+ pages of interlinked rules of what is what, what does what and in what order, then comparing that to how system behaves after your changes
Lol just kidding. No business rules are harder than five lines of text
Code normally works fine after you write it and then hopefully at least test by hand. The new guy 5 years later, which do not fully grasp the extent of his actions, and the guy reviewing the code also not being too familiar with it, will not make sure everything does as intended.
Tests are correctness guarantees, and requires the code and/or the test to change to pass. They also explain how something should behave to people that don’t know. I work in a area where there are so many businesses rules that there is no one person that knows all of it, and capturing the rules as tests is a great way to make sure that rules remains true after someone else comes to change the code.
This might work when the test really describes&tests the business rule, not when the test simply contains a mirror of the implementation with everything replaced by mocks and just checks that the implementation is what it is, conditioning all people changing the code in the future to always have to change the test as well.
Tests can be messed up just like anything else can be messed up. Doesn’t mean that the concept itself is flawed.
If you only do things that people cannot mess up, then you’ll quickly end up not doing anything at all.
The biggest benefit to me that testing has is when refactoring. If I have decent test coverage and I change something major, tests help me to see if I accidentally broke something on the way, which is especially helpful if I am touching ancient code written by someone who left the company years ago.
Blech, this is my least favorite kind of testing. I’d much rather have some all-encompassing integration tests even if they’re confusing AF, than the “yep the language still works as advertised” nonsense that this approach often amounts to.
Capturing the rules as documentation is also a great way to make sure that rules remain true.
Lol just kidding! Documentation … can you imagine?
Capturing the rules as documentation (especially external documentation like confluence) is a great way to make sure nobody ever reads it. Or even finds it.
Yeah, good luck reading 20+ pages of interlinked rules of what is what, what does what and in what order, then comparing that to how system behaves after your changes
Lol just kidding. No business rules are harder than five lines of text