3 ms·

At Google they draw the distinction based on i/o. Anything that does i/o wouldn't be considered a unit test by them. Unit tests are usually for algorithms, math

by jart 3y ago

At Google they draw the distinction based on i/o. Anything that does i/o wouldn't be considered a unit test by them. Unit tests are usually for algorithms, math functions, data structure classes, and stuff like that. Most developers have never needed to write any of those things because they're abstracted by modern languages, which is why I suspect the terminology confuses some people.

randomdata 3y ago
Unit testing in the realm of software originated from the Smalltalk world, where a unit described the test suite for a class. That, with some liberty around the use of class in languages that are not class-centric, reflects the vast, vast, vast majority of tests I see out there in the wild. The reality is that unit testing swept the world and has become synonymous with testing. The days of yore when things like capture and replay testing were it are behind us. Today, it is uncommon for anyone to write anything other than unit tests (as originally defined). And that's why "unit testing" has become confusing. Its original meaning no longer serves a purpose. Today, we just call it "testing", leaving those who wish to continue to use "unit" for the sake of fashion to invent pet definitions; definitions not shared by anyone else.
kerkeslager 3y ago
That's a useful distinction for creating a shared language within Google, and it might be a useful distinction for your team too. But it's definitely not the only way to divide things up. The important thing is that the terminology your term uses is useful for your team. One project I'm working on has two kinds of tests: unit tests run within the code and test classes, state transitions, etc. by calling the code directly, while integration tests are run in Selenium in a headless browser from the perspective of the user. Some of the unit tests on models do hit the DB (i.e. they do I/O).

by jart 3y ago

randomdata 3y ago

Unit testing in the realm of software originated from the Smalltalk world, where a unit described the test suite for a class. That, with some liberty around the use of class in languages that are not class-centric, reflects the vast, vast, vast majority of tests I see out there in the wild. The reality is that unit testing swept the world and has become synonymous with testing. The days of yore when things like capture and replay testing were it are behind us. Today, it is uncommon for anyone to write anything other than unit tests (as originally defined). And that's why "unit testing" has become confusing. Its original meaning no longer serves a purpose. Today, we just call it "testing", leaving those who wish to continue to use "unit" for the sake of fashion to invent pet definitions; definitions not shared by anyone else.

kerkeslager 3y ago

That's a useful distinction for creating a shared language within Google, and it might be a useful distinction for your team too. But it's definitely not the only way to divide things up. The important thing is that the terminology your term uses is useful for your team. One project I'm working on has two kinds of tests: unit tests run within the code and test classes, state transitions, etc. by calling the code directly, while integration tests are run in Selenium in a headless browser from the perspective of the user. Some of the unit tests on models do hit the DB (i.e. they do I/O).