4 ms·

We have a good coverage, but we don't have that feeling that after running all tests we can release. Currently each dev decides how much tests to write, but usu

We have a good coverage, but we don't have that feeling that after running all tests we can release. Currently each dev decides how much tests to write, but usually after the fact to make sure whatever he wrote behaves as expected, at that time. The problem arises when some changes are made and random tests are failing and it becomes more difficult to fix.

AnimalMuppet 7y ago
No, when some changes are made, very specific tests start failing, and that conveys some information. (It can take some work to sort out what the information means, though...) How does it become more difficult to fix? Because you have to fix the tests, too? Don't just fix them. Use them as a guide to where to think a bit more. "This change broke that test. Is that telling me that the change broke the assumptions of that code, and that therefore the change is wrong? Or is it just that the test itself didn't expect this?" You should know which it is before you fix a test. I think the situation you're describing here is not TDD-vs-after-the-fact-testwriting. It's incomplete-vs-close-to-complete test coverage.
- rooam-dev 7y ago
  Could be. You could have close to complete coverage, but slow integration tests. Not a big problem, CI can run those all the time. The problem is the feedback cycle. The slower the tests, the slower the feedback is. So, with each change I have to wait for integration test to run. There is a difference between 2 seconds and 20... it's ok intially but later feels like restarting the server just see if my changes work. I think and hope with TDD (or some sort of it) to get everyone into a discipline mode, which will lead to better tests. Coverage should follow. Anyway, I think it's worth trying, but it needs commitment and discipline, similar to agile... it has to be tried as a team.

4 ms·

We have a good coverage, but we don't have that feeling that after running all tests we can release. Currently each dev decides how much tests to write, but usu

by rooam-dev 7y ago

AnimalMuppet 7y ago
No, when some changes are made, very specific tests start failing, and that conveys some information. (It can take some work to sort out what the information means, though...) How does it become more difficult to fix? Because you have to fix the tests, too? Don't just fix them. Use them as a guide to where to think a bit more. "This change broke that test. Is that telling me that the change broke the assumptions of that code, and that therefore the change is wrong? Or is it just that the test itself didn't expect this?" You should know which it is before you fix a test. I think the situation you're describing here is not TDD-vs-after-the-fact-testwriting. It's incomplete-vs-close-to-complete test coverage.
- rooam-dev 7y ago
  Could be. You could have close to complete coverage, but slow integration tests. Not a big problem, CI can run those all the time. The problem is the feedback cycle. The slower the tests, the slower the feedback is. So, with each change I have to wait for integration test to run. There is a difference between 2 seconds and 20... it's ok intially but later feels like restarting the server just see if my changes work. I think and hope with TDD (or some sort of it) to get everyone into a discipline mode, which will lead to better tests. Coverage should follow. Anyway, I think it's worth trying, but it needs commitment and discipline, similar to agile... it has to be tried as a team.