Ive seen people define unit test as something that could use a database. I've seen others vehemently disagree with this.
"Unit" is not a particularly well defined thing.
I think this lack of agreement is part of the problem coz it makes it impossible to have a conversation with these terms.
For this reason I usually avoid talking about unit tests and try to use something a bit more specific (e.g. xUnit framework test) to highlight what I mean.
> "Unit" is not a particularly well defined thing.
Fair point. I think in this case I would stop focusing on definitions and focus on goals. Saying that one goal with our unit tests is for them to be lightening fast, so disk access including hitting the database is not allowed. Feel free to write a "unit test" that hits the database. But we are going to run that "unit test" along with our slower running tests that we call "functional tests".
I really don't get the position that a test that is potentially harder to write (because mocks) and catches fewer bugs (because mocks) but takes 0.1 seconds to run instead of 3 seconds is intrinsically "better".
It's not intrinsically better. It's just a different type of test. And which type of test you want to use and when is going to be based on your goals as an organization. 5000 unit tests times 3 seconds is 4 hours, isn't it? Compared to 9 minutes in the former case. That matters in some organizations.
"Unit" is not a particularly well defined thing.
I think this lack of agreement is part of the problem coz it makes it impossible to have a conversation with these terms.
For this reason I usually avoid talking about unit tests and try to use something a bit more specific (e.g. xUnit framework test) to highlight what I mean.