Unit tests and test driven development seem to be an acquired taste of programmers.

It takes a while to appreciate its taste, but once you get used to it, you just can't go without it anymore.

@fribbledom I have like one app I make that has tests. Probably not "unit tests". More like " conformance tests that just happen to make sure stuff works." But it does what I need. 🤷‍♂️

@fribbledom Unit tests have saved my ass so many times over the years, more so when the LOC gets into the 100k or higher range.

But I agree, I've struggled to teach my team about testing. More so when they waste three days trying to fix the wrong problem and I remind them "break it first, then fix it."

"I'll remember it next time."

No, they won't.

@dmoonfire @fribbledom Getting into unit tests is hard when you start on a big project that is structured so that it's hard to write unit tests. *sighs*

@anke @fribbledom Yeah. But it's nice after a few years when you can make a change with confidence.

I have a tendency to refactor heavily when I code so testable patterns emerge as a natural result. I just know as a human, I'm great at breaking things but usually at regressions.

@fribbledom I prefer to use languages which have rich enough type systems to avoid needing to test many of the basic cases and leave only logic errors that are hard to express through types unless you want to use a dependent type system

@lunch @fribbledom That reminds me... is there a programming language that doesn't require you to specify the datatype, but will pick one for you at compile/parse time? Kind of like C++'s `auto`, but more powerful.

@Parnikkapore @fribbledom are you just asking about type inference? most languages with functional heritage use type inference for local binding, but some take it farther and use it for every bind including function arguments

@fribbledom Generally speaking I learned to appreciate TDD. But I usually have a hard time writing tests for software that I don't start from scratch. And for my latest example I feel like sometimes the software architecture becomes more complex than needed to "simplify testability" (for example by performing unnecessary dependency injection).

@fribbledom I'm not completely sold on TDD, but on unit tests I had that experience, more or less... and where I'm more diligently applying test I've been saved a couple of times already from refactoring/development snags.

@fribbledom I WANT to test, but have no idea how to begin retrofitting tests into a giant monolithic codebase.

@fribbledom Unit tests are a must, but test driven development is an error prone method of analysis. It's popular with "coders" (those who feel that code is their most important output), because it represents continuous coding. Management likes it, because they get to remove some of what they consider overhead in their processes. (i.e., it helps move coding closer to a manufacturing process than a knowledge process.)
The real problem is the loss of independent test.

It's one of those things which takes time to wrap you head around, more time to get some practice, and still more until you spend less time setting up (and debugging!) and using unit tests than debugging your code the oldfashioned way.

At least that's what I tell myself because I haven't yet done it yet. But that's what forcing myself to learn/use object-oriented programming (as an engineer, surrounded by FORTRAN users) was like, and expect to face a similar curve with unit tests.

@fribbledom One of my ex-CEO: Unit tests cannot be sold to the customer.
Me: But bugs can be?
Him: If you have worked on that given task only, you won't have those bugs now.
Me: (That's bullshit!) Hmm.

Try to convince those people who are to narrowly focused on making money ...


Depends a bit on what you're working exactly, but generally speaking: yes, these tests can and *should* be sold to your customers.

I'm just glad your ex-boss isn't head of a bridge construction company 😄

@fribbledom Automated testing is crucial for any large project, as pointed out by others these tests provide confidence when refactoring or otherwise changing things around, and can really save your butt.

However, true unit tests are generally overrated (many developers enshrine them as a dogma). Unit tests are supposed to literally be testing one unit, so no other classes (in OOP) should be under test. Unit testing is extremely useful if a class does something complicated.

@fribbledom However, in a typical design there are classes that do structural or organizational things, and unit testing these classes is pretty much useless.

Furthermore, testing the API of every class is going to cause issues when you go to refactor. Now, you have to change both the class and all the tests associated with the class.

Why add additional cost for little to no benefit? This cost can get huge if these things are done to the extreme.

@fribbledom I've found that in addition to unit tests for complex classes, it's best to use high level integration tests or end-to-end tests.

You generally have some part of your API that needs to stay stable (passive), so you should use that API for your testing.

This isn't perfect of course, it can be hard to make high-level automated tests that are fast enough to be useful, but there's a lot of libraries and frameworks to help with that these days.

@fribbledom @urusan And very simple to add to your .git/hoooks/pre-commit script.
Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!