DevOps Zone is brought to you in partnership with:

I'm software developer and microISV, with a lot of passion to technologies.. having a fun writing code, writing blog posts and giving public speeches. For about 10 years of total experince I've been working in many branches of software development, including management and QA. I try to follow and adopt agile practices and signed up for software craftsmenship manifesto. Alexander is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

Integration or Unit Tests Trade-Off

  • submit to reddit

Recently, I released small Express.js extension for easy switching application to maintenance mode. Sometimes, you just want to run patch against database or change the infrastructure of product, but instead of showing blank nginx 503 error page, you want to have nice looking HTML, saying will be back soon.

The maintenance package is now available on npm and you welcome to use it. But I would like to share the way I developed and test it.

So, maintenance is a function that takes app instance and options as a parameters. Then it augments app with additional endpoint (if there is such preference) and injects middleware function that would render maintenance page in case of mode is set to true.

It’s really small piece functionality, but still I wanted to make sure, it’s gonna work in my application without annoying restarts of servers and debugging the stuff. And TDD is right approach to solve the pain.

TDD is quite commonly trade-off of unit tests and integration tests. And it’s always up to developer which direction go in particular case. Let’s take a look on my case:

If you go unit test way, it would be something like that:

  • call maintenance function, pass mock of express instance
    • verify that new route is added after function completes
    • verify that all route.callbacks now have callback to check the mode
    • verify that route.callbacks[0] contains mode check function
  • call route.callbacks[0], mock req and res object
    • verify that res.render called with maintanance.html argument
    • etc..

Is all of that kind of suck? It is, since it would take too much effort for mocking the stuff.. But more important, all of that is nothing more as just testing of implementation details of Express.js, but not behavior details of application.

Now, let’s consider integration tests way for same stuff:

  • run application in normal mode
    • send HTTP GET and make sure that response is fine
  • run application is maintenance mode
    • send HTTP GET and make sure that response contains maintenance page
  • run application in normal mode
    • send HTTP GET and make sure that response is fine
    • sent HTTP POST to maintenance endpoint
    • send HTTP GET and make sure that response contains maintenance page

Does it look like real behavior testing? Indeed, test acts as user and checks that application actually behaves right, doesn’t matter of implementation details.

With spending more time with Express.js and Node.js I see much more value in integration way of testing. It’s very easy to spin-up a server and send HTTP requests and check responses.

If you are interested, check out specification and test application.

Published at DZone with permission of Alexander Beletsky, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mateus Dubiela ... replied on Sun, 2014/05/04 - 5:52pm

Nice post!

But doing both wouldn't be a more Test oriented way? I mean, why throw away unit tests? 

Behaviour tests should agree with your application's contract. Unit test are made to support your development and guarantee quality.

Why should you not use any of then?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.