Hacker News Reader

Comment by mattmanser | Hacker News Reader

You're not describing unit tests, they're integration tests.

You've fallen into the very trap of terminology the author mentions at the beginning of the article.

Actually no, the "unit" in unit tests is about isolation: the test can be executed as an independent unit, not about a unit of code (single class/method). If you search around, the leading experts who popularized unit tests described it as such.

It is perfectly fine to test multiple classes as a unit, in fact you probably already do so, as I would be extremely surprised if you mock your string class in all your unit tests.

If you have to 'search around' for your definition and make a dubious appeal to authority without citing any of those experts, perhaps you need to wonder if it's your definition that's wrong.

It was not my intention to present you with such a major challenge, my deepest apologies.

https://martinfowler.com/bliki/UnitTest.html

Martin Fowler

Although I start with the notion of the unit being a class, I often take a bunch of closely related classes and treat them as a single unit.

https://medium.com/@_ericelliott/i-use-the-well-known-defini...

Kent Beck

Unit tests test individual units (modules, functions, classes) in isolation from the rest of the program

Although I start with the notion of the unit being a class...

Such great evidence.

Further in the article he goes over exactly why he feels that its allowed to both test a single class or multiple at once, going as far to give a name to them: solitary vs sociable unit tests.

Then, he goes on to, and let me emphasize this, defend against the criticism that other people make that this type of test is not a unit test. (sound familiar?):

Indeed using sociable unit tests was one of the reasons we were criticized for our use of the term "unit testing". I think that the term "unit testing" is appropriate because these tests are tests of the behavior of a single unit. We write the tests assuming everything other than that unit is working correctly.

I'm not sure how thoroughly you're looking to be refuted here but I feel I can't quite do a better job.

Funny thing is, this is not even a very deep insight: the answer to nearly any question in software design can be boiled down to: it depends. This discussion is just the unit-test rendition of "it depends". Why are you so hell bent on having it exactly one way?

I think I'm disagreeing with the definition implied by the article. To me, an integration test involves integrating with another system.

Testing groups of functions or classes together is still a unit test, by Wikipedia's definition at least

"unit testing is a software testing method by which individual units of source code—sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures—are tested to determine whether they are fit for use" [1]

and by Michael Feather's definition

"A test is not a unit test if:

- It talks to the database

- It communicates across the network

- It touches the file system

- It can't run at the same time as any of your other unit tests

- You have to do special things to your environment (such as editing config files) to run it." [2]

Indeed, it's the inevitable result of doing TDD; the refactor step is likely to break out smaller classes/functions already covered by the existing tests. If we write new, more granular tests every time we do the refactor step, then we end up with brittle tests.

[1] https://en.wikipedia.org/wiki/Unit_testing

[2] https://www.artima.com/weblogs/viewpost.jsp?thread=126923

Edit: To clarify, I'm not talking about calling the public API over the network, I'm talking about the public methods that consumers (including your network layer) would call.

That might be where the confusion lies here.

To me, an integration test involves integrating with another system.

That's not what it means, and the author clearly indicated it didn't?

When your colleagues are talking to you, you're going to be constantly misunderstanding them if you just make up your own definitions, even after they explained them!

When I was 14 I believed @ meant about and now I no longer use @ to mean about.

Reply on news.ycombinator.com