Recently, I’ve 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.
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.
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
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:
maintenancefunction, pass mock of
routeis added after function completes
route.callbacksnow have callback to check the mode
route.callbackscontains mode check function
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:
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.