hinthealth / facade Goto Github PK

Got this message: 'Expected', 'owner', 'to equal', Object{id: 1, name: 'Membership Owner'}, 'in', Object{owner: Object{id: 1, name: 'Membership Owner'}}, 'but it was', Object{id: 1, name: 'Membership Owner'}

That looks like that should work. Not sure what the deal is.

was doing...

var postParams = {owner:{ id: 1, name:"Membership Owner"}}
chargeResource.expect('POST').with(postParams);

chargeResource was

  var chargeResource = Facade.resource({
    name: 'charge',
    url: '/api/provider/charges',
    createDefault: function(postData) {
      var defaultCharge = Replicator.build('charge');
      return _.extend({}, defaultCharge, postData);
    }
  });

all the controller was doing was

    function createCharge(charge, payment) {
      if (!_.isEmpty(payment)) { charge.payment = payment; }

      chargeService.create(charge)
        .then(function(){
          $window.analytics.track('Charge Created', {patientId: vm.patient.id});

and was able to fix by instead doing...
$httpBackend.expect('POST', '/api/provider/charges', postParams);

so we can do something like expect GET /some/url, {ok: 'go'} and it will match:

GET /some/url?ok=go
GET /some/url?some=param&ok=go

but not

GET /some/url?some=param&ok=gototown

see: https://gist.github.com/melcher/57fb98d2ac7102652b3a

Something like...

Facade.define(function() {
  Facade.resource({name: 'company', url: 'blah/blah' });
 });

This will make it so it's less dependent on order of includes (If you wanted to use Replicator in the callback, for instance). It also makes it so that this setup can actually run every time when initialized, so that it's fresh every time. Rather than keeping it in some separate file than can only run once.

Certain routes totally might not use the DB, or they only send down 202's or what have you. You should be able to set this, so that Facade doesn't put things in the DB, and thus won't care if the post data doesn't have an id, or whatever.

You should be able to do something like...
Facade.findRoute('GET blah').expect(); // Passing in nothing should just set up an expectation, passing in an object should do the loose matching.

would be good to have a deleteAll method, and also like find({name: "Joe"}) or something like that so you can find on more than just id, which is a bit cray cray

I could see it being convenient to just do something like...
resource.addRoute({method: "POST", route: "/blah", response: blah}) and it can either be an object, or an array with four things as the whole response.

Use Graham's thing where it loosely matches params being sent up. Probably something like...

verifyRoute.expect('GET').with(params)

This would be awesome if facade could deal with the httpBackend.flush madness. Like, perhaps check on every scope.apply, and do a try/catch with httpBackend.flush(); Or something...

request some examples:

limit
offset
filter
sort
expand

response examples:

x-total-count
pagination stuff

If you have a patientResource, and then do patientResource.resource({name: 'charge', url: 'blah})

and then try to do... chargeResource.addRoute({....}), it will fail, with
'undefined' is not an object (evaluating 'facadeRoutes[opts.resource.name].

This is because the nesting of resources doesn't run through the same code path as Facade.resource. Dumb!

I just want to call something like... Facade.showRoutes() and have it output something like...

GET /api/provider/patients
GET /api/provider/patients/pat-293jSK3j
POST /api/provider/patients
etc., etc.

The add item should be able to take an array of items. Something like...
Facade.db.patient.add([patient1, patient2]).

see: https://gist.github.com/melcher/57fb98d2ac7102652b3a

If just calling expect actually creates an expectation (but not expecting any params), then calling the .with should just add params to that expectation that it will look at in the callback.

should also probably error if you try to call with after the callback has run.

So in the callback, probably do something like expectationRan = true

And it will probably need some closure scope stuff to make the callback work properly.

If you do an expectation thing, Facade should default to checking the under a parent param, and that parent param should default to the name of the resource, unless you specify otherwise in the with call.

Since you can make routes with a regex, you should be able to expect with them as well.

Really not much need to be hiding all that much. It comes in handy sometimes.

Upon initialization, it should make sure to just clear everything out. Do Facade.clear(), then run the rest of initialize as normal

Unsure if this is super useful, but i could see wanting to ensure that a parameter is not sent up, but not wanting to specify every parameter with a withExactly. Could be something like ".without('foo')".

expectation = resource.expect('POST')
expectation.without('foo')
// Would fail with POST /patients  {foo: undefined, bar: 'anything, even foo', bar2: 'foo'}
// Would fail with POST /patients  {foo: 'ok', bar: 'no'}
// Would succeed with POST /patients  {bar: 'anything'}
// Would succeed with POST /patients  {}

If you have a patient route, and then you nest a charge route underneath of it, it doesn't auto handle the nested routes for each of the items within the parent resource. That is, you don't end up with 'patient/id/charges/charge_id', and you totally need to.

Something like a withExactly that only will succeed if the parameters match exactly what is passed up. For when we want to be anal about something being passed up.

expectation = resource.expect('POST')
expectation.withExactly({foo: 'bar'})

it currently uses console logs and the karma output is not useful

LOG: 'Expected', 'email', 'to equal', '[email protected]', 'in', Object{first_name: 'Joey', last_name: 'Cash', email: '[email protected]', phone_number: '4151234567'}, 'but it was', '[email protected]'
PhantomJS 1.9.8 (Mac OS X) Profile spec should update the user information FAILED
    Error: Expected PATCH /api/user with different data
    EXPECTED: function (postData) {
          var jsonData = JSON.parse(postData);
          if (!jsonData) {
            console.log("Unable to parse to JSON:", postData);
            return false;
          }
          return _.all(expectedParams, function (expectedValue, expectedKey) {
            return findParam(jsonData, expectedValue, expectedKey);
          });
        }
    GOT:      {"user":{"first_name":"Joey","last_name":"Cash","email":"[email protected]","phone_number":"4151234567"}}
        at $httpBackend (/Users/owner/hint/provider-portal/bower_components/angular-mocks/angular-mocks.js:1148)
        at sendReq (/Users/owner/hint/provider-portal/public/vendor/js/all.js:26405)
        at /Users/owner/hint/provider-portal/public/vendor/js/all.js:26145

Tables may come with params that are nested under some parent param, such as...{patient: {email: "[email protected]"}}. Currently, such patches will fail, because they don't know to apply only the thing nested under the parent param.

My guess is it should be assumed to use a nested param that matches the name of the resource, unless specified as an option when creating the resource.

You should be able to do something like...
Facade.db.patient.add({id: 2, name: "joe"}). It should just do the same thing as using the resource object does currently, which is like... patientResource.addItem({id: 2, name: "joe"}).

You should be able to do something like...

Facade.resource({
  name: 'user',
  url: '/api/user',
  singleton: true
});

And this would make all the rest routes WITHOUT ids. So everything would just be '/api/user', and there wouldn't be an "index" action, per se.

BUG on identical keys at different depths

Given the following request

{
  "test": true,
  "patient": {
    "id": 400,
    "category": {"id": 10, "name": "Person"}, "practitioner": {"id": 35, "name": "Dr. Sammy"}
  }
}

It's impossible to match against the category or practitioner id. Matching on {"id": 10} will fail on the patient and never be attempted against the category or practitioner match.
Matching on name works with {"name": "Person"} but will print an error message even when the test succeeds. These should probably be addressed first.

Proposed improvement to matching

Given the following request

{
  "test": true,
  "patient": {
    "id": 400,
    "category": {"id": 10, "name": "Person"}, "practitioner": {"id": 35, "name": "Dr. Sammy"}
  }
}

I'm proposing the following tests would pass:

patientResource.expect(PATCH, '/patients').with({patient: {id: 400}});
patientResource.expect(PATCH, '/patients').with({patient: {category: {id: 10}}});
patientResource.expect(PATCH, '/patients').with({patient: {practitioner: {id: 35}}});
patientResource.expect(PATCH, '/patients').with({test: true});
// By default we'll ALSO try all matches with the singular resource name prepended, so the following
// would also match
patientResource.expect(PATCH, '/patients').with({id: 400});
patientResource.expect(PATCH, '/patients').with({category: {id: 10}});
patientResource.expect(PATCH, '/patients').with({practitioner: {id: 35, name: "Dr. Sammy"}});
// Even with this feature, bare values would continue to match like this:
patientResource.expect(PATCH, '/patients').with({test: true});

And any of the following should fail:

// ID match fails because the value doesn't match (35 != 400)
patientResource.expect(PATCH, '/patients').with({id: 35});
// Fails because there's no key 'name' on patient or the root object
patientResource.expect(PATCH, '/patients').with({name: "Dr. Sammy"});
// Succeeds on id: 10, but fails on name "Person" != "Dr. Sammy"
patientResource.expect(PATCH, '/patients').with({category: {id: 10, name: "Dr. Sammy"}});
// Fails on id value as 35 != null
patientResource.expect(PATCH, '/patients').with({practitioner: {id: null}});
// ID match fails because 400 != the categories ID of 10
patientResource.expect(PATCH, '/patients').with({category: {id: 400}});

calling resource.expect creates an expectation, calling .with causes the expectation to pass/fail depending on those parameters, calling .with would chain the expected parameters so that each would need to pass.

  var expectation; // Instantiate it so it can be shared between calls
  beforeEach(function(){
    expectation = resource.expect('POST');
   // every it block now requires a post to happen
  });
  it("should expect a post", function(){
    // Fails because we don't click save
  });
  it("should succeed post happens with any parameters", function(){
      click('Create'); // succeeds with any parameters
  });
  context("with a name", function(){
    beforeEach(function(){
      expectation.with({name: 'Joey'}); // now requires the parameters {name: 'Joey'}
      fill('Name').with('Joey');
    });

    it("should send up the patient's name", function(){
      click('Create');
    });
    describe("with a phone number", function(){
      it("should send up the phone number", function(){
        fill('Phone number').with('415-555-1234');
        expectation.with({phone_number: '415-555-1234'});
        // Extends the expectation, now requires name: 'Joey' and phone_number:  '415-555-1234'
        click('Create');
      });
    });
  });
``