td.verify not returning true when true

[reharik]

sorry didn't know how to phrase this. Basically I'm stubbing a function, calling it the calling td.verify.
from the td.explain it certainly looks like it should verify. I tried to do some debugging but it seems that collections are mutated when examining them. It seems like verify is calling pop and then in calls.wasInvoked the call the store is empty. I'm thinking it's getting popped to examine and then popped again. Anyway here are the results.
Here are the results

==========td.explain(repositoryStub)=========
{ callCount: 1,
calls: [ { args: [Object], context: [Object] } ],
description: 'This test double repository has 1 stubbings and 1 invocations.\n\nStubbings:\n - when called with ("/home/rharik/Development/writersTools/writer_key/wk_api/app/src/repositories/sql/activity.sql", "get_activity_by_id", {id: 1}), then return {id: 123, title: "hello"}.\n\nInvocations:\n - called with ("/home/rharik/Development/writersTools/writer_key/wk_api/app/src/repositories/sql/activity.sql", "get_activity_by_id", {id: 1}).',
isTestDouble: true }
==========END td.explain(repositoryStub)=========
1) should call repo
when calling activity get
[info] module: wk_api msg: Selecting activity 1 from repository | 2:24:23 pm
✓ should return proper body properties

1 passing (50ms)
1 failing

1. Container Test #ACTIVITY CONTROLLER ACTIVITY when calling activity get should call repo:
   Error: Unsatisfied verification on test double repository.

Wanted:
- called with ("/home/rharik/Development/writersTools/writer_key/wk_api/app/src/repositories/sql/activity.sql", "get_activity_by_id", {id: 1}).

But there were no invocations of the test double.
at Object.fail (node_modules/testdouble/lib/log.js:21:13)
at Object.module.exports [as verify] (node_modules/testdouble/lib/verify.js:28:20)
at Context._callee$ (app/tests/controllers/activityControllerTester.js:49:14)
at tryCatch (node_modules/regenerator-runtime/runtime.js:64:40)
at Generator.invoke [as _invoke] (node_modules/regenerator-runtime/runtime.js:299:22)
at Generator.prototype.(anonymous function) [as next] (node_modules/regenerator-runtime/runtime.js:116:21)
at step (app/tests/controllers/activityControllerTester.js:3:191)
at app/tests/controllers/activityControllerTester.js:3:361
at process._tickCallback (internal/process/next_tick.js:103:7)

[searls]

I'm sorry but in order to make heads or tails of what you're observing, we'll need a minimal code example that reproduces the issue.

[reharik]

Sure, but I'm afraid, I don't know the best way to do that. I'll provide a gist of the actual files. If you need more please guide me on the format to provide.
The code being tested is in a koa2 server controller.
https://gist.github.com/reharik/ce99d99796905fa1c46d65f07c3959ac

if you wanted to I would love to hear ( or be pointed to ) a best practice for this sort of thing. I often find issues in code, but my code is deeply embedded in an application. I never know what people want to see, if there is some common format for submitting code for issues.
Thanks,
ps I really like this library. reminds me a lot of the functionality I miss from rhinomocks in c#
thanks again.
r

[searls]

Ok, let's try this. For a node library like this, the best thing you can do is:

1. Create a reproducible project repo (or better: a https://runkit.com executable notebook), not a gist, so I don't have to go and create a project and whatever fakes I need to run your test
2. Use ES5. Don't get fancy with anything that'd require a transpiler
3. Once you have a working example cut-cut-cut everything that isn't necessary to reproduce the bug. I've wasted hours tracking down example issues that turn out to be incidental complexities of the provided example

[reharik]

Yes, that's awesome. That's just the sort of info I was hoping to get, and runkit ( if it is what it seems to be ) is just the sort of tool I was hoping to find out about. Seems like your little run down there should be posted somewhere. Thanks for the help, Im off to figure out runkit and will get back with you. R

…

On Fri, Mar 3, 2017 at 10:45 AM, Justin Searls ***@***.***> wrote: Ok, let's try this. For a node library like this, the best thing you can do is: 1. Create a reproducible project repo (or better: a https://runkit.com executable notebook), not a gist, so I don't have to go and create a project and whatever fakes I need to run your test 2. Use ES5. Don't get fancy with anything that'd require a transpiler 3. Once you have a working example cut-cut-cut everything that isn't necessary to reproduce the bug. I've wasted hours tracking down example issues that turn out to be incidental complexities of the provided example — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA12zhvCKA9DkLXmdfAn8IZiBMngD07Eks5riEOegaJpZM4MRfQS> .

[reharik]

I'm sorry to have to ask you but I have this runkit
https://runkit.com/reharik/testdouble-issue
not sure how to get mocha tests to run in it. It says it doesn't have a reference to describe. I'm guessing since you mentioned it and you work on a testing tool you might have some insight.
Thanks.
R

[searls]

@reharik since td.js isn't coupled to any test framework, you shouldn't need a test framework to replicate the issue. just do it as a script

[reharik]

tru dat!
good point ok can you try again
https://runkit.com/reharik/testdouble-issue
I think it actually illustrates my problem. I was worried that when I stripped it all down I'd find I had done something ridiculous. Probably still have but I don't see it.
https://runkit.com/reharik/testdouble-issue

[searls]

Oh, I can see your issue now.

Calling td.verify() on its own is not supported. verify() is for making sure that a function was called for which there's no other way to verify that (e.g. when the doubled function has a side effect and doesn't return something).

In your case, the when is all you really need, because you should be able to inspect the return value of your subject under test to ensure that the repository was called as you expected (after all, if it wasn't called as expected, the subject would never get the activity back!).

Here's a (quite reworked) example that's closer to how I'd write this test:

var expect = require('chai').expect;
var td = require('testdouble');

var ACTIVITY_SQL = 'some/path';

var testTarget = function (repository) {
  return {
    activity: function(ctx) {
      var activity = repository(ACTIVITY_SQL,'get_activity_by_id', ctx.params);
      ctx.status = 200;
      ctx.body = {
        status: ctx.status,
        success: true,
        data: activity
      };
      return ctx;
    }
  }
}    


var repository = td.function('.repository');
var subject = testTarget(repository);
td.when(repository(ACTIVITY_SQL, 'get_activity_by_id', {id: 1})).thenReturn('some activity');

var result = subject.activity({params: {id: 1}});

expect(result.status).to.eq(200);
expect(result.body).to.deep.eq({
  status: 200,
  success: true,
  data: 'some activity'
});

And it passes in this runkit demo

[reharik]

Ok. that works, I remember reading that strategy somewhere in the docs but then I couldn't find it again. On the one hand I learned a lot with this issue :) on the other hand I wonder if td.verify() should throw or give a more specific error message. But I'm too fried right now to think it through. I'll take the solution and run. Thanks a lot for the help! R

…

On Fri, Mar 3, 2017 at 2:26 PM, Justin Searls ***@***.***> wrote: Oh, I can see your issue now. Calling td.verify() on its own is not supported. verify() is for making sure that a function was called for which there's no other way to verify that (e.g. when the doubled function has a side effect and doesn't return something). In your case, the when is all you really need, because you should be able to inspect the return value of your subject under test to ensure that the repository was called as you expected (after all, if it wasn't called as expected, the subject would never get the activity back!). Here's a (quite reworked) example that's closer to how I'd write this test: var expect = require('chai').expect;var td = require('testdouble'); var ACTIVITY_SQL = 'some/path'; var testTarget = function (repository) { return { activity: function(ctx) { var activity = repository(ACTIVITY_SQL,'get_activity_by_id', ctx.params); ctx.status = 200; ctx.body = { status: ctx.status, success: true, data: activity }; return ctx; } } } var repository = td.function('.repository');var subject = testTarget(repository);td.when(repository(ACTIVITY_SQL, 'get_activity_by_id', {id: 1})).thenReturn('some activity'); var result = subject.activity({params: {id: 1}}); expect(result.status).to.eq(200);expect(result.body).to.deep.eq({ status: 200, success: true, data: 'some activity' }); And it passes in this runkit demo <https://runkit.com/searls/58b9becbca2b280014b7abc5> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#191 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA12zl8w_GvWsmCNO3tPfq0K3pREvye4ks5riHeQgaJpZM4MRfQS> .