I'm sorry, i didn't agree at all. TDD is documentation and testing together. If you forget to update the test when a function changed, the tests will fail. Deprecated documentation does not fail. Once you have deprecated documentation you don't rely on it because you don't know which one is updated and which one didn't.
About the reading complexity of the test suites, you can try with BDD and gherkins.
A method in programming has to explain what it does within the function name.
You like to read, then after your mentions about TDD I think that you really don't know TDD. I recommend you reading first the: Test-Driven Development by Example (Kent Beck), from the mastermind of it.
Yes, completely agree. Documentation that is not automatically validated against the code for correctness is the worst kind imho. This is because over time it becomes outdated and paints a different picture of what the system is doing and how; and it will get outdated.
However imho the code + the tests, together, form a self validating single source of truth of documentation. The tests document what the system does and the code documents how it does it.
And they both keep each other honest.
Thank you !
Comments in code are just noise and they're practically never up to date. Unit tests are there to specifiy a behavior (business rules) you can easily use the tests as documentation. The truth (what the product actually does) is in the code not in the documentation, tests are there to be sure behavior didn't changed and act as documentation, i never trust documentation i only trust what i see in the code
I'm sorry, i didn't agree at all. TDD is documentation and testing together. If you forget to update the test when a function changed, the tests will fail. Deprecated documentation does not fail. Once you have deprecated documentation you don't rely on it because you don't know which one is updated and which one didn't.
About the reading complexity of the test suites, you can try with BDD and gherkins.
A method in programming has to explain what it does within the function name.
You like to read, then after your mentions about TDD I think that you really don't know TDD. I recommend you reading first the: Test-Driven Development by Example (Kent Beck), from the mastermind of it.
Yes, completely agree. Documentation that is not automatically validated against the code for correctness is the worst kind imho. This is because over time it becomes outdated and paints a different picture of what the system is doing and how; and it will get outdated.
However imho the code + the tests, together, form a self validating single source of truth of documentation. The tests document what the system does and the code documents how it does it.
And they both keep each other honest.
Thank you !
Comments in code are just noise and they're practically never up to date. Unit tests are there to specifiy a behavior (business rules) you can easily use the tests as documentation. The truth (what the product actually does) is in the code not in the documentation, tests are there to be sure behavior didn't changed and act as documentation, i never trust documentation i only trust what i see in the code
Talk about reading, let's read too "Why are we yelling? : the art of productive disagreement" by Buster Benson.