{"action":"created","issue":{"url":"https://api.github.com/repos/testdouble/testdouble.js/issues/379","repository_url":"https://api.github.com/repos/testdouble/testdouble.js","labels_url":"https://api.github.com/repos/testdouble/testdouble.js/issues/379/labels{/name}","comments_url":"https://api.github.com/repos/testdouble/testdouble.js/issues/379/comments","events_url":"https://api.github.com/repos/testdouble/testdouble.js/issues/379/events","html_url":"https://github.com/testdouble/testdouble.js/issues/379","id":353072192,"node_id":"MDU6SXNzdWUzNTMwNzIxOTI=","number":379,"title":"mocking non-direct dependency","user":{"login":"sarneeh","id":11553624,"node_id":"MDQ6VXNlcjExNTUzNjI0","avatar_url":"https://avatars2.githubusercontent.com/u/11553624?v=4","gravatar_id":"","url":"https://api.github.com/users/sarneeh","html_url":"https://github.com/sarneeh","followers_url":"https://api.github.com/users/sarneeh/followers","following_url":"https://api.github.com/users/sarneeh/following{/other_user}","gists_url":"https://api.github.com/users/sarneeh/gists{/gist_id}","starred_url":"https://api.github.com/users/sarneeh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sarneeh/subscriptions","organizations_url":"https://api.github.com/users/sarneeh/orgs","repos_url":"https://api.github.com/users/sarneeh/repos","events_url":"https://api.github.com/users/sarneeh/events{/privacy}","received_events_url":"https://api.github.com/users/sarneeh/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-08-22T18:31:41Z","updated_at":"2018-09-21T13:28:20Z","closed_at":"2018-08-24T20:12:32Z","author_association":"NONE","body":"### Description\r\nI would like to use `testdouble` for integration tests to mock some dependencies and make tests more predictable and easier to write/read. In this particular example, I'd like to mock a deep, non-direct dependency of a module. Let me explain, you have something like this:\r\n\r\nsubject:\r\n```js\r\nconst dep1 = require('./dep1');\r\nmodule.exports = () => dep1();\r\n```\r\n\r\ndep1:\r\n```js\r\nconst dep2 = require('./dep2');\r\nmodule.exports = () => dep2();\r\n```\r\n\r\ndep2:\r\n```js\r\nmodule.exports = () => {};\r\n```\r\n\r\nLet's say that the subject is a `express` route handler (`subject`) which saves data to the database (`dep1`), which generates an unique UUID for the entry before saving (`dep2`). I'd like to mock the returning UUID's to easily check the new entries in the database.\r\n\r\nFor this I'd create an integration test, but to introduce this example as simply as possible let's stay with the easy things above. So let's have this test:\r\n\r\n```js\r\nconst t = require('tap');\r\nconst td = require('testdouble');\r\n\r\nlet dep2, subject;\r\nt.beforeEach(done => {\r\n  dep2 = td.replace('./dep2');\r\n  subject = require('./subject');\r\n  done();\r\n});\r\n\r\nt.afterEach(done => {\r\n  td.reset();\r\n  done();\r\n})\r\n\r\nt.test('1', async t => {\r\n  td.when(dep2()).thenReturn(1);\r\n\r\n  const result = subject();\r\n\r\n  t.equal(result, 1);\r\n});\r\n\r\nt.test('2', async t => {\r\n  td.when(dep2()).thenReturn(2);\r\n\r\n  const result = subject();\r\n\r\n  t.equal(result, 2);\r\n});\r\n```\r\n\r\n### Issue\r\n\r\nSo the first test passes, but the second one does not. `dep2` returns nothing, and `td.explain()` shows that there are `0` stubbings.\r\n\r\nWhat am I doing wrong? 😄 \r\n\r\n### Environment\r\n\r\n- node: 9.11.2\r\n- npm: 5.6.0\r\n- testdouble: 3.8.1"},"comment":{"url":"https://api.github.com/repos/testdouble/testdouble.js/issues/comments/423530890","html_url":"https://github.com/testdouble/testdouble.js/issues/379#issuecomment-423530890","issue_url":"https://api.github.com/repos/testdouble/testdouble.js/issues/379","id":423530890,"node_id":"MDEyOklzc3VlQ29tbWVudDQyMzUzMDg5MA==","user":{"login":"searls","id":79303,"node_id":"MDQ6VXNlcjc5MzAz","avatar_url":"https://avatars1.githubusercontent.com/u/79303?v=4","gravatar_id":"","url":"https://api.github.com/users/searls","html_url":"https://github.com/searls","followers_url":"https://api.github.com/users/searls/followers","following_url":"https://api.github.com/users/searls/following{/other_user}","gists_url":"https://api.github.com/users/searls/gists{/gist_id}","starred_url":"https://api.github.com/users/searls/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/searls/subscriptions","organizations_url":"https://api.github.com/users/searls/orgs","repos_url":"https://api.github.com/users/searls/repos","events_url":"https://api.github.com/users/searls/events{/privacy}","received_events_url":"https://api.github.com/users/searls/received_events","type":"User","site_admin":false},"created_at":"2018-09-21T13:28:20Z","updated_at":"2018-09-21T13:28:20Z","author_association":"MEMBER","body":"In that case, I won't send the Mocking Police after you if you were to use a mocking library to fake out the third party thing, but I'd still be reticent because it'd leave you exposed to the possibility of that fake inaccurately mimicking a failure state of the lib such that the test is creating fake work for you. Or (more likely), as the lib changes the fake you write today does mimic the real failure state successfully but future versions of the lib will fail differently.\r\n\r\nIn either case I'd write a thin wrapper module around it, call through that, and fake _that_, but to each their own."}}
{"actor":{"display_login":"searls"}}