{"action":"created","issue":{"url":"https://api.github.com/repos/FakeItEasy/FakeItEasy/issues/951","repository_url":"https://api.github.com/repos/FakeItEasy/FakeItEasy","labels_url":"https://api.github.com/repos/FakeItEasy/FakeItEasy/issues/951/labels{/name}","comments_url":"https://api.github.com/repos/FakeItEasy/FakeItEasy/issues/951/comments","events_url":"https://api.github.com/repos/FakeItEasy/FakeItEasy/issues/951/events","html_url":"https://github.com/FakeItEasy/FakeItEasy/issues/951","id":195742506,"number":951,"title":"Configuring a call on a strict fake without Returns","user":{"login":"thunderbird55","id":23313056,"avatar_url":"https://avatars.githubusercontent.com/u/23313056?v=3","gravatar_id":"","url":"https://api.github.com/users/thunderbird55","html_url":"https://github.com/thunderbird55","followers_url":"https://api.github.com/users/thunderbird55/followers","following_url":"https://api.github.com/users/thunderbird55/following{/other_user}","gists_url":"https://api.github.com/users/thunderbird55/gists{/gist_id}","starred_url":"https://api.github.com/users/thunderbird55/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thunderbird55/subscriptions","organizations_url":"https://api.github.com/users/thunderbird55/orgs","repos_url":"https://api.github.com/users/thunderbird55/repos","events_url":"https://api.github.com/users/thunderbird55/events{/privacy}","received_events_url":"https://api.github.com/users/thunderbird55/received_events","type":"User","site_admin":false},"labels":[{"id":28627148,"url":"https://api.github.com/repos/FakeItEasy/FakeItEasy/labels/discussion","name":"discussion","color":"cc317c","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-12-15T08:15:31Z","updated_at":"2016-12-16T10:18:54Z","closed_at":null,"body":"Hi,\r\ndue to issue #899 I upgraded FakeItEasy from version 2.1.0 to 2.3.2 and mentioned a different behavior.\r\nIn 2.1.0 if a call to a strict fake is configured without a return then the calls to the fake work and the default value is returned. \r\nIn 2.3.2 there is only an exception with the message \"Call to non configured method \"Bar\" of strict fake\".\r\n\r\nIn my opinion the new behavior is ok but a better message would be nice, something like: \r\n\"Call to configured method \"Bar\" of strict fake has no return specification\"\r\n\r\n```c#\r\npublic interface IFoo\r\n{\r\n    bool Bar(string x);\r\n}\r\n\r\n[TestMethod]\r\npublic void TestMethod1()\r\n{\r\n    var fake = A.Fake<IFoo>(x => x.Strict());\r\n    A.CallTo(() => fake.Bar(A<string>.Ignored)); // In 2.1.0 the default value was returned\r\n    Assert.IsFalse(fake.Bar(\"Foobar\")); // In 2.3.2 an exception is thrown\r\n}\r\n```"},"comment":{"url":"https://api.github.com/repos/FakeItEasy/FakeItEasy/issues/comments/267562118","html_url":"https://github.com/FakeItEasy/FakeItEasy/issues/951#issuecomment-267562118","issue_url":"https://api.github.com/repos/FakeItEasy/FakeItEasy/issues/951","id":267562118,"user":{"login":"thunderbird55","id":23313056,"avatar_url":"https://avatars.githubusercontent.com/u/23313056?v=3","gravatar_id":"","url":"https://api.github.com/users/thunderbird55","html_url":"https://github.com/thunderbird55","followers_url":"https://api.github.com/users/thunderbird55/followers","following_url":"https://api.github.com/users/thunderbird55/following{/other_user}","gists_url":"https://api.github.com/users/thunderbird55/gists{/gist_id}","starred_url":"https://api.github.com/users/thunderbird55/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thunderbird55/subscriptions","organizations_url":"https://api.github.com/users/thunderbird55/orgs","repos_url":"https://api.github.com/users/thunderbird55/repos","events_url":"https://api.github.com/users/thunderbird55/events{/privacy}","received_events_url":"https://api.github.com/users/thunderbird55/received_events","type":"User","site_admin":false},"created_at":"2016-12-16T10:18:54Z","updated_at":"2016-12-16T10:18:54Z","body":"> As you say, a good part of our resistance is technical: due to the form of the API, it's not that easy to tell when configuration is done. We say A.CallTo. Maybe we're done, maybe we aren't. Things could be done to detect this situation, but at a cost in extra code complexity and runtime performance.\r\n\r\nOk, then I would say let's close this issue. I thought maybe there is only an additional if necessary.\r\n\r\n> We're getting more tangential here, but it's a shame about ReSharper.\r\n> \r\n> The warning thing is something to consider, but years ago at my Day Job we picked it up and started using it on a legacy project. There are certainly lots of warnings (of course, tunable), but we've contented ourselves with cleaning up a file as we touch it (or for truly monstrous files, picking a class of warning at a time within the file) and gradually enjoying the improvement.\r\n> As time goes by, the heavily-trafficked files get cleaned up very quickly, and the infrequently visited ones less so, but hey, they're probably infrequently visited because they work well enough, so the approach is working for us.\r\n> \r\n\r\nI totally agree with you. In my former company we had a similar approach.\r\nIn my current company the philosophy is \"don't change anything\". But better we don't talk about this because I'm getting angry when I'm thinking about this :("}}
{"actor":{"display_login":"thunderbird55"}}