loopback testing with mocha, models, and supertest

[Dakotah North]

Piggybacking on the discussion about depreciating loopback-testing https://groups.google.com/forum/#!topic/loopbackjs/w038RvqHeYI

 I followed the simple-data-source example from the github example directory and combined that with Mocha test idioms to get the following:

describe('/Student', function () {

    var server = require('../server/server')
    var loopback = require('loopback')
    var supertest = require('supertest')
    var request = require('supertest')(server)

    var Student = dataSource.define('Student', {
        'id': Number,
        'points': Number
    });

    beforeEach(function () {
        Student.updateOrCreate({id: 1, points: 5000});
    })


    it('Post a new student', function (done) {
        request.post('/api/Students').send({points: 5000}).expect(200, done)

    })


})

I really like using the model to do operations and for a single file this worked *really* well.

The problem is, once I introduced another test file (say test-teacher.js) which also defines a Student from a datasource, tests starting failing in ways that didn't make any sense.

So ... am I missing something or have I combined two different ideas in a way that doesn't work?

[Brett Kotch]

Also asked this on Stack Overflow http://stackoverflow.com/questions/35005001/loopback-testing-with-supertest-mocha-and-models

After iterating over several ways of doing this, the code below allows me to run as a single suite. 

Pasted from Stack Overflow

I create a model instead of using server.model.Student. This apparently enables the models that are created to bypass the model creating code before save and after save. 

This obviously has pros and cons. The pro being that the initialization code (Student.updateOrCreate) is not limited to the validation code that I have in the model. Which is obviously also the con. With the code below, I am able to run all the tests from multiple different models as a single suite using npm test without any failures.

In the case of Student, there is code which prevents the id from being explicitly set (so it nice to simply bypass that code using create Model.) I don't know if this was the intention, but it is a nice side-effect to simplify initializing the instances. 

describe('/Student', function () {

    var server = require('../server/server')

var request = require('supertest')(server)

    var dataSource = server.dataSource('db', {adapter: 'memory'})

    var Student 

    before(function() {
        Student = dataSource.createModel('Student', apps.models.Student)    
    

}


    beforeEach(function () {
        Student.updateOrCreate({id: 1, points: 5000});
    })


    it('Post a new student', function (done) {
        request.post('/api/Students').send({points: 5000}).expect(200, done)

    })


})

[Brett Kotch]

This unit test has its challenges because I am creating a new datasource. 

In a nutshell ... it looks like the data that is created from request.post and the data that is created from the dataSource directly (via Student.createOrUpdate) have different (for lack of a better word) repositories. 

It would be *REALLY REALLY* helpful, if someone from the loopback.io team actually spent a few hours and wrote up an example of how to tests looback applications. 

I can easily say that, by far the most difficult aspect of using loopback for me is properly writing unit tests. 

[Líus Fontenelle Carneiro]

Hi!

A testing guide on LB would be nice. I'm splitting my tests into integration (HTTP API tests) and functional (Node API). If is necessary to change the datasource, I use datasource config file and set environment variable NODE_ENV. One benefit from this approach is that is not necessary to change test source code when is necessary swap datasources.

Best Regards,

Líus

[Jonathan Eustace]

I too would like a guide on writing unit tests for loopback. 

[Boštjan Pišler]

Yes a guide would be great. Can't get it completely right.

[notbrain]

A guide on testing, I too, would like. 

Especially one that shows the best way to allow tests to account for after save hooks. A simple arbitrary timeout delay? Our tests end up deleting data on cleanup before the after save hooks complete. Is this a failure to write after save hooks properly or just the "side effect" nature of the after save hook itself?

[Boštjan Pišler]

Yes, testing examples would be very welcome!