I'm building a node.js web app and am trying to do so for the first time in a test driven fashion. I'm using nodeunit for testing, which I find allows me to write tests quickly and painlessly. In this particular app, the heavy lifting primarily involves translating SQL data into complex Javascript object and serving them to the front-end via json. Likewise, the app also spends a great deal of code validating and translating complex, multidimensional Javascript objects it receives from the front-end into SQL rows. Hence I have used a fat model design for the app -- most of the real code resides in the models, where the data translation happens.

What's the best approach to test such models with unit tests? I mean in particular the methods that have create javascript objects from the SQL rows and serve them to the front-end. Right now what I'm doing is making particular requests of my models with the unit tests and checking the returned data for all of the fields that should be there. However I have a suspicion that this is not the most robust kind of testing I could be doing. My current testing design also means I have to package my app code with some dummy data so that my tests can anticipate the kind of data that the app should be returning when tests run.


Specific question:

Does it make sense to inject a testing layer between my model and my database? Or would it be better to let the models work on a real database with pre-defined test data inserted into it?

The second option I imagine will probably result in more accurate testing, but the first model seems more versatile in terms of granularity and makes the testing and development more portable (no db required)

1 Answer 1


Create a Repository or Service layer that acts as a go-between for your model and frontend, and write mock objects for that Repository or Service layer.

The Service Layer provides an interface surface that you can mock. You can either inject a fake or stub that mimics the behavior of the Service Layer, or use a library to create mock objects. Data layers don't do this well because, while they do adequately represent your data domain, they don't adequately model business processes and, well, who wants to mock a DAL anyway?

So, if you create a Service Layer or Repository Layer, this will afford you a layer of abstraction between your database classes and your frontend. You can then mock that service layer and mimic some business domain-specific service behavior for testing your frontend classes.

  • Wait, so the Service layer would be the test? Or would the test work on the service layer directly?
    – rgb
    Commented May 29, 2014 at 19:27
  • See my update... Commented May 29, 2014 at 19:48
  • Hey Robert thanks for your thoughtful answer. However, I've already got a good test setup for the backend that does not involve the front-end at all. What my questions asks if specifically how to test the model components of my back-end. Meaning this: does it make sense to inject a testing layer between my model and my database? Or is it better to let the models work on a real database with pre-defined test data inserted into it?
    – rgb
    Commented Jun 2, 2014 at 14:53
  • As with many things in computing, it depends. Some people use a lightweight alternative database like SQLite as a stand-in, but that of course does not substitute for actual integration testing with a real database. I personally prefer not to test mundane operations like CRUD calls at all. Commented Jun 2, 2014 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.