Kent Beck, credited with coining the term "unit test", defines unit tests as tests that run without affecting other tests. In other words, unit tests are tests that do not introduce side-effects. I suggest that if you are writing anything other than unit tests, as originally defined, in this day of age, you are doing something horribly wrong. Side-effects is how you end up with tests that randomly break, which is a nightmare for those running them. A good software steward would not deem that acceptable.

I've seen some other definitions out there, but they didn't make any sense. Obviously someone was trolling in those cases. Presumably you were thinking of one of them? Absolutely you wouldn't write tests that don't make any sense. I am not sure why anyone would.

▲

RaftPeople 4 days ago | parent [-]

> Kent Beck, credited with coining the term "unit test"

The term "unit test" has been used since the 1960's (if not earlier).

▲

9rx 4 days ago | parent [-]

Definitely not. The Art of Software Testing wrote about "module testing" in 1979, which was revised as "unit testing" in a later revision after "unit test" was part of the popular lexicon. Perhaps that is what you are thinking of?

Beck is clear that he "rediscovered" the idea. People most certainly understood the importance of tests being isolated from each other in the 1960s. Is that, maybe, what you mean?

	▲	RaftPeople 15 hours ago \| parent [-]
		Link to ACM paper from 1969 https://dl.acm.org/doi/epdf/10.1145/800195.805951 Quote: "Unit test: testing, outside of thesystem, of a part of the system thatmay have less than a complete function. Component test: testing, inside of the system, of parts that have been successfully unit tested. Integration test: testing of new components to ensure that the system is growing functionally; in addition, retesting of successive system builds to ensure that they do not cause re-gression in the capabilities of the system. Regression test: testing of the system for unpredictable system failure. Scaffolding: coding that replaces not - yet - completed functions..." I was taught in the 80's about this by a woman that had worked at some company that was more formal about software dev than we were at the small company I worked for.