"Unit testing is, not surprisingly, the act of testing a "unit" in your application."
"Unit testing" means your tests are "units", as in non-divisible, independent things.
@juliobiason wait, are you saying that all non-divisible automated tests are unit tests, no matter if they operate on one function, on whole program, or on whole program with database and operating system underneath?
@Wolf480pl Yup, although "database" and "filesystem", in some cases, may be considered as external resources and should be mocked.
For example, you can run the whole program, but if it accesses some external site, you just mock it -- and you _still_ have a unit test.
@juliobiason I guess 2/3 of the industry is wrong then.
@Wolf480pl And that's why current software sucks so much.
@juliobiason I think current software sucks so much because of scope creep and lack of attention to performance. Wrong testing may or may not be on the 3rd place.
@Wolf480pl Well, we can argue that "scope creep" means the software is doing a lot of stuff.
But imagine if you write one test for each behavior.
Then, when you get a larger scope, you will write more tests for those scopes and, with previous tests checking the old behavior, you can be sure that even with that, things are still working.
... or, at least, that's what I get from "scope creep".
@Wolf480pl (Not saying "YOU WRONG! ME RIGHT!", but it seems you can get around scope creep -- at least, the way I see it, and I reckon I may be wrong here -- with proper testing.)
@Wolf480pl Sure, this way of seeing testing against scope creep may also create a new problem of test creep and how do you manage that you're not testing two opposite situations, but hey, one problem at the time! :)
>testing two opposite situations
That'd actually be a good thing.
It'd give you a hint that you're doing something wrong and need to remove a feature or two.
@juliobiason scope creep means that software that does too many things, and there's no bound of how much things is enough, so it'll keep growing new functionality.
This in turn will increase complexity, while decreasing performance, interoperability, and ability to reason about the piece of software.
Even if your tests make sure you don't introduce new bugs, the software still can become slow, big, or inconsistent.
Moreover, with simple software it's easy for a user to predict how the software will behave in a particular situation, which means the user will be able to use the software:
- more safely
- more effectively
- for usecases which the original author didn't consider.
By making your software complex, you're making it harder for users to gain this kind of understanding.
@Wolf480pl This definition comes more from Kent Beck (you know, the guy who wrote the "Test Driven Development" book), which he says that and that you should test "behavior" and not "implementation" (so, testing a function may be completely wrong.)
@juliobiason I'm going to test this individual unit of code to make sure it adds one to what it was given. It's called unit testing a mono-add or monad.
So, I'm not suggesting that your view is wrong, only that most people would go along with thinking about the (size of the) unit of code under test.
There's apparently a paper from the 70s even by David Panzl wherein he describes the progenitor to the xUnit-style tests but it's locked behind a paywall. It'd be interesting to read.
If you've got sources to support your claim, feel free to share them.
(Just to show you how the fuck condescending tone you asked for this, but it starts around 11:42, the behavior part is around 19:05, about around 25:50 is goes about clean code, refactor and such around TDD.)
The first three pages of results on any search engine re: unit testing go against what you're saying, so the onus is kind of on you to back up your statements. If you don't want people questioning you, don't toot the kind of thing you started this out with.
You could've just asked "Hey, can you point where I can find the reference in this?" and it would be fine. You could even point that you don't have that much free time in your hands, and that's also fine.
But when you put "expect me to do" so and so, you're getting into a "holy than thou" attitude which isn't nice.
And it gets really aggressive 'cause we never had any kind of exchange and you simply jumped into the conversation with a "I know everything and the internet agrees with me" attitude.
But it did _sound_ like that (and I admit that the tone I posted was exactly the way I felt, although one can see that the tone changed completely in the next reply) and that's why I answered like that.
@kungtotte @schaueho But, if we go back to the topic at hand, there is also a good video from Gary Bernhardt about "Fast Tests, Slow Tests" which kinda speaks a bit differently: https://www.youtube.com/watch?v=RAxiiRPHS9k
(Sorry, it's, again, something you need to watch it all, 'cause the whole argument is way more nuanced than simply three lines or one paragraph.)
@kungtotte @schaueho The crux is that Gary pushes towards making tests around classes (it's Ruby+Rails) for fast testing around each layer (tests for models, tests for controllers [without models] and tests for views), so it runs really fast. But you still need to write "integration" tests; and, if those tests run in isolation, as Cooper puts in its presentation, isn't it an unit test as Beck describes?
@schaueho It was my bad, sorry.
@juliobiason so when you post a toot like https://functional.cafe/@juliobiason/103221999362491028 where you take the established views on something and say "WROOONG", you don't have a "you're wrong" or a "I know everything" attitude? I have that attitude when I reply to you, but you don't when you start off on that foot? Is that about the gist of it?
Hot tip: when you say everyone is wrong, expect some push back on that and be prepared to defend your views properly.
functional.cafe is an instance for people interested in functional programming and languages.