7
uyouthe
333d

I promised to blow off unit tests, so here we go. Let’s talk about unit tests.

Why use them? So, unit testing connoisseurs outline two big purposes:
1. To keep application integrity,
2. To catch bugs.

Keeping app integrity is when your freshly hired developer implement something that potentially leads to the whole app failure, but unit test fails and tell you that newly added code is breaking the app.

Catching bugs is pretty much self explanatory. Just think about it – you have to actually write code that describes how to check up another code to catch bugs in it.

I personally hate unit tests. I can’t explain, but every time I forced myself to write them, I got vertigo and terrible headache to the end of the day. Trying to write some tests? Here you go, wooosh and you can’t work anymore. Go get some sleep if you can.

But I still needed my job to be done and it should have been done really well. So I started my research.

Recalling Steve McConnell’s and many other classy developers’ experience, there is only one decent solution that prevents bugs and inconsistencies at large scale – the specs. Developing the specs should be considered the task number one. With decent, robust specs, app is almost guaranteed to contain no bugs.

Let’s take a look at the piece of great spec. For example, imagine you have to implement validation logic. So you state that validation should be implemented with special validation functions and then you define what validation function is: a pure function that accepts a value and returns boolean: true if value is good, false otherwise.

With that in mind, it’s obvious that potentially present bugs can only be inside that pure functions. Our spec made implementing validation very easy and idiomatic, isolating potential bugs. As soon as validators are pure and simple, unit tests aren’t needed at all.

You know what? As your app scales, you’ll definitely need a spec, sooner or later. Growing up without spec leads to irreversible failure, your app will grow like cancerous cell does and it’ll be easier to just put it into trash and start up from scratch.

But specs have one major downside – it requires at least one enlightened developer with really great experience to create it. It can’t be done quickly, it’s a very costly and difficult process. That’s why making great software costs that much.

But what if you need an MVP right now?

Speaking of MVPs, you’ll have to go with simplest instruments possible. Throw away Jenkins, use your Plesk autodeploy from Git repo. Throw away complex frontend setups, go with $30-$40 glittery ui kit or even an open source thing right from CDN, without less, sass, gulp and all that jazz. Make use of create-react-app if you can’t avoid using React because you’re making a web application.

Throw away AWS, Azure, Docker, Kubernetes and everything like that. Buy a cheap PHP7 hosting with pre-installed MySQL and do everything as simple as possible. If you have to use NoSQL, go with free Heroku with git autodeploy, NodeJS Express and free Mongo addon.

MVP should be ready in two weeks. As soon as your infrastructure is that simple, you don’t need unit tests. They’ll slow you down. Once you MVP is ready, go get funding, throw away first MVP, hire a decent CTO and let him create the spec.

Right there, it may be noticeable that unit tests are probably the biggest and baddest workaround imaginable. It gives you false sense of controlling your bugs, while you don’t have any control at all. Obvious bugs that unit tests can catch are easily noticeable at concise system, while quirky bugs couldn’t be caught by them because you can’t even imagine them while writing your unit tests. At this point, unit tests are just waste of time.

So, the whole picture is clear: at a small scale, you don’t have time to write unit tests and don’t have many bugs because of simple tools and standard patterns. At large scale, you need a spec to prevent bugs, unit tests become redundant as long as your spec is good.

In conclusion, I can tell that I’ve been developing a Clojurescript + CouchDB app for some startup, and in 8 month coding by spec I made myself I encountered only two or three bugs, all related to external JS tools and its quirks.

Have a good time!

Comments
  • 4
    I’ll ++ first

    Then I read
  • 1
    @devTea "Keeping app integrity is when your freshly hired developer implement something that potentially leads to the whole app failure, but unit test fails and tell you that newly added code is breaking the app. "

    That is simply not true. Even if it were true, you know which parts of the code NOT break the app, which in itself is valuable information.

    "Catching bugs is pretty much self explanatory. Just think about it – you have to actually write code that describes how to check up another code to catch bugs in it."

    What is wrong with that? Also, nobody expects you to write test cases for EVERYTHING at the beginning. You are expected to add a testcase if you know it breaks your code. Its an iterative process.

    Also you only write that code ONCE. It is not much overhead with modern testing frameworks to do so, and tdd makes you think more about your actual expectation of a piece of software.

    BTW: Unit tests are NEVER the only tests that are running.
  • 0
    "Keeping app integrity is when your freshly hired developer implement something that potentially leads to the whole app failure, but unit test fails and tell you that newly added code is breaking the app."

    It's way more and valuable than that. Unit tests tell you how the new code impacts on the old one, where it's ok and where you breaking the app. By doing so, tests are actually telling you how and where to fix. Then go, fix, unit tests maybe are broken again, fix again, and again till everything it's green. At the end you'll have refactored your codebase the safest way.

    Unit tests are far from being the ultimate bugcatcher device. Actually, they really don't have that much to do with bugs.

    What is true is that effective unit tests requires certain characteristics in a codebase, and many old school projects (like many in the java1 to 6 era) are simply and unfortunately often not shaped this way.
  • 1
    @thatsnotnice unit tests and tdd in general are more of a mindset than anything else. It is really hard to add unit tests to legacy code appropriately, simply because unit tests need decent modularity of your code.
  • 0
    @muma it seems like you’re the only one who understands what I’m talking about
  • 1
    Sometimes tdd is a religion too
  • 0
    Ignoring everything else - imagine this - releasing an app without a knot of worry in your stomache for days in a row. That alone makes proper testing worth it.

    Now moving on we can think about how unit testing and the open closed principle work together to help you think about building a product you can have tons of confidence in. You wrote small methods that are well tested. They're closed for modification - you're good! No worries about that code. You extend the service and reuse some existing already tested code? Great! You can be confident that a large chunk of that new code is already tested.

    The real question is; why live in fear of a shit storm when you can live happy and watch netflix, scratch your balls and get paid for delivering something that you know works thanks to your integration and acceptance tests?
Your Job Suck?
Get a Better Job
Add Comment