2 ms·

You’re talking about integration tests, not unit tests. Unit tests should focus on a single method. Integration tests can combine methods/objects/APIs/etc for b

by exdsq 6y ago

You’re talking about integration tests, not unit tests. Unit tests should focus on a single method. Integration tests can combine methods/objects/APIs/etc for business rules. Your best bet is a combination of unit tests, integration tests, and e2e tests (there’s some old advice about a 70/20/10 split but this is pretty arbitrary).

UK-Al05 6y ago
Yes this what has spread around and what people think of as unit tests. But it an awful way of splitting tests. Code bases following this end up with brittle tests, that break at slightest design change with no functional change. Here's a good article kent beck retweeted on the subject. https://twitter.com/KevlinHenney/status/1266383805520084993 https://twitter.com/KevlinHenney/status/1266383805520084993 I define unit tests as fast, and don't cross architectural boundaries, and operate on a well defined public interface. And test some kind actual property you care about. I don't follow "strict" rules like unit test per class, per function etc. A lot classes just extract to some to some helper class, and they operate well together and the helper is not likely to be used anywhere else. Just make the helper class private and test as a unit against some actual desired property you want to test. Integration tests is when you bring external things into the mix like databases, or http calls.
- afarrell 6y ago
  > just make the helper class private Yes, if your class is small enough to not make sense to test, make it private.
chriswarbo 6y ago
If you want to make that argument, that's fine. What I would encourage you to do is define the terms you're using, and don't assume that others are using certain words in the way that you mean them. I like that you've been explicit about your definitions here (although it may be better to describe rather than assert, e.g. "I treat unit tests as focusing on a single method", rather than "Unit tests should focus on a single method"). For what it's worth, I find the definitions you're using to be harmful (e.g. see http://chriswarbo.net/blog/2017-11-10-unit_testing_terminology.html http://chriswarbo.net/blog/2017-11-10-unit_testing_terminolo... and http://chriswarbo.net/blog/2020-07-07-more_testing_terminology.html http://chriswarbo.net/blog/2020-07-07-more_testing_terminolo... )
- Huggernaut 6y ago
  You may enjoy this write up on testing taxonomy: https://blog.7mind.io/constructive-test-taxonomy.html https://blog.7mind.io/constructive-test-taxonomy.html
  - chriswarbo 6y ago
    Indeed, especially having an axis extending from an individual function/method up to third-party services would presumably stop the "everything is a class" creep that's happened to so much testing terminology already.
ragnese 6y ago
There's more recent debate about what a "unit" is. The parent reply is not wrong. We're just using different definitions.

by exdsq 6y ago

UK-Al05 6y ago

Yes this what has spread around and what people think of as unit tests. But it an awful way of splitting tests. Code bases following this end up with brittle tests, that break at slightest design change with no functional change. Here's a good article kent beck retweeted on the subject. https://twitter.com/KevlinHenney/status/1266383805520084993 https://twitter.com/KevlinHenney/status/1266383805520084993 I define unit tests as fast, and don't cross architectural boundaries, and operate on a well defined public interface. And test some kind actual property you care about. I don't follow "strict" rules like unit test per class, per function etc. A lot classes just extract to some to some helper class, and they operate well together and the helper is not likely to be used anywhere else. Just make the helper class private and test as a unit against some actual desired property you want to test. Integration tests is when you bring external things into the mix like databases, or http calls.

afarrell 6y ago
> just make the helper class private Yes, if your class is small enough to not make sense to test, make it private.

chriswarbo 6y ago

If you want to make that argument, that's fine. What I would encourage you to do is define the terms you're using, and don't assume that others are using certain words in the way that you mean them. I like that you've been explicit about your definitions here (although it may be better to describe rather than assert, e.g. "I treat unit tests as focusing on a single method", rather than "Unit tests should focus on a single method"). For what it's worth, I find the definitions you're using to be harmful (e.g. see http://chriswarbo.net/blog/2017-11-10-unit_testing_terminology.html http://chriswarbo.net/blog/2017-11-10-unit_testing_terminolo... and http://chriswarbo.net/blog/2020-07-07-more_testing_terminology.html http://chriswarbo.net/blog/2020-07-07-more_testing_terminolo... )

Huggernaut 6y ago
You may enjoy this write up on testing taxonomy: https://blog.7mind.io/constructive-test-taxonomy.html https://blog.7mind.io/constructive-test-taxonomy.html
- chriswarbo 6y ago
  Indeed, especially having an axis extending from an individual function/method up to third-party services would presumably stop the "everything is a class" creep that's happened to so much testing terminology already.

ragnese 6y ago

There's more recent debate about what a "unit" is. The parent reply is not wrong. We're just using different definitions.