Should we deprecate this module (and or rebuild it)?

[ritch]

Context

It seems like several people have started using this module. I original authored this to scratch my own itch:

https://github.com/strongloop/loopback/blob/master/test/access-control.integration.js

I had a ton of access control tests to write. Typically we just write a utility method in a test file or in a supports.js or util file somewhere to reduce the redundancy of test setup. The issue with the access control tests was that even it() and describe() were becoming somewhat repetitive.

This Module

Enter this testing module, it was initally written within loopback and specifically that file linked above. It reduced the definition of access control tests from 5-10 lines each to 1 liners.

The issues

• generating tests means you have to do weird hacks like this
• beforeEach is essentially hard coded into the helpers
• poorly documented / not written with intent for community consumption
• mocha specific :(

Question

Should we deprecate this module? We have several pull requests that we might as well land, but probably should discourage new contributions and instead willing devs should spend effort in a better direction (eg. mocha agnostic test utils).

[bajtos]

+1 for deprecating this module. I think the test data builders are useful on their own, so I'd like to keep them - either in this module or in a standalone one.

[jrschumacher]

@ritch yes I think deprecating this would be advisable. It is a good start, but as people start developing more advanced applications it actually becomes a hinderance. I would suggest a new repository of "testing recipes" which would be a series of tips or examples on how one could test an app.

At the same time this was something that really attracted me to Loopback. This lowered the bar on implementing tests and meant I could start my app with tests in place. However after using this I would now have preferred to use Chai HTTP since time is limited and this repo doesn't seem to make the cut.

[bajtos]

An idea: perhaps we can write a supertest/superagent wrapper instead of mocha helpers?

var request;
beforeEach(function() { request = supertest(app); });

describe('as authenticated user', function() {
  beforeEach(function(done) {
    createUser.then(loginUser).then(function(token) { 
      request.set('Authorization', token.id); 
      done();
    });
  });

  it('should allow GET /items', function(done) {
    request.get('/items').expect(200).end(done);
  });
  // etc.
});

[bajtos]

However after using this I would now have preferred to use Chai HTTP since time is limited and this repo doesn't seem to make the cut.

Nice, I didn't know about Chai HTTP. I especially like the promise support, AFAIK superagent/supertest do not support promises yet.

[csvan]

@ritch what is the current outlook for this module? Will it continue to be maintained? Just asking since we are looking for a solid way to test our backend/API in a current project, and this repo if definetly on the list.

[jrschumacher]

@csvan after using this I would suggest exploring chai extensions. This was a good launchpad but we've had to make a number of hacks to keep it afloat for our infrastructure. Save yourself the pain and use widely maintained tools.

[csvan]

@jrschumacher thanks for the headsup, we are leaning towards that conclusion as well.

For anyone interested, a strong candidate which we are evaluating right now is frisbyjs (http://frisbyjs.com/), which is developed on top of Jasmine exclusively for testing REST APIs. We are very impressed with it so far.

[TimPerry]

Has a decision been made yet? This module seemed to be working for us before we started doing anything with ACL's but since we have started setting up ACL's I am starting to see some real pain.

@csvan I had looked at using frisby before trying this module but feel that supertest would be better suited? As this project appeared to be a wrapper around supertest I thought it was worth a shot but I think I might just use supertest on it's own and see how I get on.

[csvan]

Tim, we settled for Supertest and it is working great so far. I am not
aware of any better alternative at this point.

On Sun, 15 Nov 2015 23:32 Tim Perry notifications@github.com wrote:

Has a decision been made yet? This module seemed to be working for us
before we started doing anything with ACL's but since we have started
setting up ACL's I am starting to see some real pain.

@csvan https://github.com/csvan I had looked at using frisby before
trying this module but feel that supertest would be better suited? As this
project appeared to be a wrapper around supertest I thought it was worth a
shot but I think I might just use supertest on it's own and see how I get
on.

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

Best,

Christopher Svanefalk

Web: http://www.csvanefalk.com
GitHub: https://github.com/csvan
LinkedIn: https://www.linkedin.com/in/csvanefalk
Cell: +46762628251
Skype: csvanefalk

[jrschumacher]

@csvan would you mind putting a gist together on how you used supertest?