Follow

"Unit testing is, not surprisingly, the act of testing a "unit" in your application."

WROOONG!

"Unit testing" means your tests are "units", as in non-divisible, independent things.

That's the start of the "Testing" chapter in Pyramid documentation.

Maybe that's why Pyramid testing is so terrible: They got it wrong from the very start...

@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 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! :)

@juliobiason
>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 @Wolf480pl The line gets blurred when the mockup is a test network or test database. I can never tell when I transition from unit testing to integration testing.

@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.

@juliobiason Wikipedia would support Pyramid on this claim.To add some more appeal to authority arguments, Martin Fowler has a discussion here:
martinfowler.com/bliki/UnitTes

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.

@schaueho @juliobiason yes, according to my cursory searching just now I can find zero sources to back up the claim that the unit is referring to the test part and not the code being tested.

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.

@kungtotte @schaueho Well, part is "anecdotory" and part is the presentation done by Ian Cooper: vimeo.com/68375232 , which is where I got the "test behavior and independent unit".

@kungtotte @schaueho (My guess is that is that kind of thing that go so distorted over the years nobody actually gets it, like OO being about messages instead of "data and behavior", which people say was the original meaning Alan Kay gave to it.)

@juliobiason @schaueho so, any timestamp you care to share or do you expect me to sit through an hour long talk to find the reference?

@kungtotte @schaueho So, any attempts to actually watch it or do you expect me to do your job?

(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.)

@kungtotte @schaueho (the whole talk is pretty interesting, actually, specially cause a lot of it fall into place due things like refactor and clean code.)

@juliobiason @schaueho you posted a statement that goes against literally every source on the internet on the topic of unit testing, then when I asked for a reference you gave me an hour long video.

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.

@kungtotte @schaueho Hey, I know the "onus of proof" (hence why I posted the times, including the ones where it gets away from it) and I don't mind being questioned.

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.

@kungtotte @schaueho That's why I called your attitude "fucking condescending". There are nicer ways to ask things, even when you want to point that there is something missing.

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.

@kungtotte @schaueho I may be wrong? Maybe, I'm not infallible and I'm the first one to admit that.

But instead of going into a conversation, you went directly into a "you're wrong!" attitude, which is what pissed me off.

And, even with that, I _did_ answer what you asked, didn't I?

@kungtotte @schaueho For one, maybe that was not the tone you wanted to come on with, mostly 'cause "tones" get lost on the texts of the internet.

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: youtube.com/watch?v=RAxiiRPHS9

(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?

@kungtotte @schaueho And if I'm writing tests for the expected behavior of the whole, why am I writing tests toward the component -- and, again as Cooper puts it, "implementation" part of the solution, which shouldn't be the focus of unit tests -- of the system?

@kungtotte @schaueho Anyway, I don't think those things are so "black and white" as everyone claims, and I can see a shitton of problem on the current "tests for functions or classes" ('cause it can lead to a lot of dead code, specially when paired with coverage) view of unit tests.

@kungtotte @schaueho And if "unit tests" are tests for functions and classes and whatever I'm talking about is not "unit tests" (quotes and all), then I have the feeling that this definition of unit tests are completely messed up.

@kungtotte @schaueho (Sorry about the wall of text and mostly spam but, again, I don't think it's that clear cut what a "unit" is, and when Cooper pointed that Beck said "behavior and in isolation", it made a lot more sense than whatever is floating around.)

@kungtotte @schaueho ('I don't think it's that clear cut what a "unit" is', even if the internet says otherwise :D )

@juliobiason @kungtotte Could you guys just drop me from your personal bashing, please? I was interested in the topic of unit tests, not so much in flame wars. Thank you.

@juliobiason so when you post a toot like functional.cafe/@juliobiason/1 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?

Cool.

Hot tip: when you say everyone is wrong, expect some push back on that and be prepared to defend your views properly.

Sign in to participate in the conversation
Functional Café

functional.cafe is an instance for people interested in functional programming and languages.