TDD is about short cycles. Normally, I code using TDD from the inside (core business rule) to the outside, so my last test implementation will be the highest test possible.
Do you mind sharing your thoughts on that as well?
TDD is about short cycles. Normally, I code using TDD from the inside (core business rule) to the outside, so my last test implementation will be the highest test possible.
Do you mind sharing your thoughts on that as well?
I would typically develop in this fashion as well. However, I have read (I think it was Kent Beck who said this, but can't recall) that you can write all the small tests you want while developing, but once you're "done" and all your tests (at the low and high level) are passing, then you can start deleting the smaller tests that don't really matter anymore. Since, the larger tests, should/would be encompassing variations of the smaller tests (similar parts of the code flow).
However, I'm still confused about how they describe "unit", to me, it sounds more like an integration test. But that could just by my misunderstanding, would love to know more.
Wow, thanks for the articles, the test contra-variance blew my mind and is probably along the lines of what this article was trying to say (but the article you linked did a better job). Moreover, it really does pair well with article 2 (I can see why you also mentioned it) because article 1 left me with the same question, should we not write tests for the ("extracted") sub-elements at all?
I think most people do some version of both of these without knowing they're doing them (myself included). But what that leads to is incomplete or "messy" test contra-variance, and redundancy.
TDD is about short cycles. Normally, I code using TDD from the inside (core business rule) to the outside, so my last test implementation will be the highest test possible.
Do you mind sharing your thoughts on that as well?
I would typically develop in this fashion as well. However, I have read (I think it was Kent Beck who said this, but can't recall) that you can write all the small tests you want while developing, but once you're "done" and all your tests (at the low and high level) are passing, then you can start deleting the smaller tests that don't really matter anymore. Since, the larger tests, should/would be encompassing variations of the smaller tests (similar parts of the code flow).
However, I'm still confused about how they describe "unit", to me, it sounds more like an integration test. But that could just by my misunderstanding, would love to know more.
Reading those both articles gave me a solid understanding how to coding behaviors test:
- Test Contra-variance by Uncle Bob (https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContravariance.html)
- Additional Testing After Refactoring by Kent Beck (https://tidyfirst.substack.com/p/additional-testing-after-refactoring?utm_source=share&utm_medium=android&r=1wkrh0&triedRedirect=true)
Wow, thanks for the articles, the test contra-variance blew my mind and is probably along the lines of what this article was trying to say (but the article you linked did a better job). Moreover, it really does pair well with article 2 (I can see why you also mentioned it) because article 1 left me with the same question, should we not write tests for the ("extracted") sub-elements at all?
I think most people do some version of both of these without knowing they're doing them (myself included). But what that leads to is incomplete or "messy" test contra-variance, and redundancy.
Thanks for the articles, worth the read!