Timeline for Where is the line between unit testing application logic and distrusting language constructs?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 22, 2016 at 3:58 | comment | added | Jonah | Let us continue this discussion in chat. | |
| Jun 22, 2016 at 3:53 | comment | added | MichelHenrich |
Sorry, I didn't make myself clear with the "no mocks involved" part. I meant I wouldn't use a mock for the savePerson function like you suggested, instead I'd test it through the more general savePeople. The unit tests for Store would be changed to run through savePeople rather than directly call savePerson, so for this, no mocks are used. But the database of course should not be present, as we'd like to isolate coding problems from the various integration problems that occur with actual databases, so here we still have a mock.
|
|
| Jun 22, 2016 at 3:37 | comment | added | Jonah | So you would you use a test database of some sort, and do asserts against that, to ensure that the test data actually go inserted as expected? Wouldn't it become an integration test at that point? | |
| Jun 22, 2016 at 3:31 | comment | added | MichelHenrich |
I'd test the whole behavior, meaning, to check if savePeople does indeed save the Person objects into the Store, no mocks involved. This does not mean the tests would be duplicated for the savePerson function - it would be tested through the savePeople function's tests. This is something Kent Beck talks about in his TDD videos and book, to test the complex part of behavior through the O(1) case, then the small variations for O(n) case, but all through the same function.
|
|
| Jun 22, 2016 at 3:11 | comment | added | Jonah |
Thanks for the update. How exactly would you test savePeople? As I described in the last paragraph of OP or some other way?
|
|
| Jun 22, 2016 at 3:05 | history | edited | MichelHenrich | CC BY-SA 3.0 |
added 1 character in body
|
| Jun 22, 2016 at 2:54 | comment | added | MichelHenrich | @Jonah updated. I hope it answers your question a bit better. This is all very opinion-based and may be against the goal for this site, but it is certainly a very interesting discussion to have. By the way, I tried to answer from the point of view of professional work, where we must strive to leave unit tests for all application behavior, regardless of how trivial the implementation may be, because we have the duty to build a well tested and documented system for new maintainers if we leave. For personal or, say, non-critical (money is also critical) projects, I have a very different opinion. | |
| Jun 22, 2016 at 2:41 | history | edited | MichelHenrich | CC BY-SA 3.0 |
Updated to better answer according to OP's comment
|
| Jun 22, 2016 at 2:16 | comment | added | Jonah | Fair and insightful points. Yet I feel somehow my real question is being dodged :) Your answer is saying, "In the real world, in a well designed system, I don't think this simplified version of your problem would exist." Again, fair, but I specifically created this simplified version to highlight the essence of a more general problem. If you can't get past the artificial nature of the example, you could perhaps imagine another example in which you did have a good reason for a similar function, which did only iteration and delegation. Or perhaps you think that it is simply impossible? | |
| Jun 22, 2016 at 2:15 | comment | added | Snoop | Basically test the interface, not the implementation. | |
| Jun 22, 2016 at 2:07 | history | answered | MichelHenrich | CC BY-SA 3.0 |