Skip to main content
8 events
when toggle format what by license comment
S Jun 26, 2014 at 7:43 history suggested Montag451 CC BY-SA 3.0
grammar and typo edits
Jun 26, 2014 at 7:42 review Suggested edits
S Jun 26, 2014 at 7:43
Jun 25, 2014 at 15:39 comment added Sam Woods If you end up calling this method from anywhere else in your code, you would have to do the same exact check for null values prior to calling the method. I would suggest actually moving the check for null values into the method itself so that you would not need repetitive code that could easily be missed. You could then have unit tests that verified if either of the values passed to the method were null that the method would skip doing anything.
Jun 25, 2014 at 10:51 comment added Falco Sorry - I think you're mixing up some bits. A Unit Test should test an input against an expected result. If the Callback is defined as "Behaviour on Null-Input is irrelevant" then your Unit-Test to test this is "if null then assert(true)". So you don't need it at all... *see my answer
Jun 24, 2014 at 20:34 comment added corsiKa In practice they end up being documentation, because they happen to be working examples. However, I would hesitate to slack on documentation just because you have unit tests. The unit tests should be testing the documented requirements. The documentation is what tells you if your tests are testing the right things or not. As for the answer itself, that's spot on. Testing for things that can never happen is the easiest test to do - you clearly have a bug (caught by the test) if you've broken some invariant like "this cannot be null".
Jun 24, 2014 at 14:45 vote accept Stu Whyte
Jun 24, 2014 at 14:15 comment added Stu Whyte I didn't think about what can happen if someone was to change code in the future. Great, Thanks.
Jun 24, 2014 at 14:08 history answered Twaldigas CC BY-SA 3.0