Timeline for Where is the line between unit testing application logic and distrusting language constructs?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 12, 2022 at 11:12 | comment | added | Gherman | The problem is, it's probably a lot easier and faster to use actual database than re-implement a huge chunk of entire database functionality as part of "just an object that implements the same interface". We don't want to re-implement all 3rd party libs as complex and huge mocks. | |
| Jul 1, 2021 at 8:17 | comment | added | Ian Goldby |
@EricDuminil Raises a very important point: myDataStore (whether it is a real database or a fake) must be reset between every unit test. You can't use a real database that might also be used by other processes.
|
|
| Jun 30, 2021 at 22:19 | comment | added | Thorbjørn Ravn Andersen | You mention usage documentation, which is perhaps even more important because you know the code is correct and up to date (or the test would fail). | |
| Sep 27, 2017 at 18:22 | comment | added | Eric Duminil |
Before calling savePeople, you probably should test that myDataStore does not contain Person('Joe'). Otherwise, if myDataStore is a database that has already been used in other tests, there might be already a Joe. If savePeople somehow stops working, you wouldn't notice it.
|
|
| Jun 23, 2017 at 17:37 | history | edited | hoffmale | CC BY-SA 3.0 |
fixed spelling, minor clarification
|
| Jul 5, 2016 at 5:53 | audit | First posts | |||
| Jul 5, 2016 at 5:53 | |||||
| Jun 22, 2016 at 20:02 | history | edited | hoffmale | CC BY-SA 3.0 |
deleted 103 characters in body
|
| Jun 22, 2016 at 19:52 | history | edited | hoffmale | CC BY-SA 3.0 |
added 4837 characters in body
|
| Jun 22, 2016 at 18:06 | history | edited | hoffmale | CC BY-SA 3.0 |
added some clarification about the mocking of the data store, changed some expressions
|
| Jun 22, 2016 at 17:56 | comment | added | hoffmale | Clarifying some of the language I used: With mock, I actually meant a stub or fake in the examples. Regarding the discussion about mocks displaying the behavior of the interface they replace: wikipedia and SO agree with me on that. Yes, you normally use mocks to verify expected method calls and parameters. No, for most unit test you don't actually have to go this far, especially if there isn't only one way to achieve a specific goal. They are really good for integration tests though. | |
| Jun 22, 2016 at 17:03 | comment | added | Jonah | "Let the mock store everything that gets added by any method for doing so in an array and check whether the test data (elements of myPeople) are in the array" -- that's still a "real" database, just an ad-hoc, in-memory one you have built. "IMHO a mock should still have the same observable behavior that is expected from a real object" -- I suppose you can advocate for that, but that's not what "mock" means in the testing literature or in any of the popular libraries I've seen. A mock simply verifies that expected methods are called with expected parameters. | |
| Jun 22, 2016 at 16:40 | comment | added | hoffmale |
it does not have to be a real database - just an object that implements the same interface as the real data store (read: it passes the relevant unit tests for the data store interface). I'd still consider this a mock. Let the mock store everything that gets added by any method for doing so in an array and check whether the test data (elements of myPeople) are in the array. IMHO a mock should still have the same observable behavior that is expected from a real object, otherwise you are testing for compliance with the mock interface, not the real interface.
|
|
| Jun 22, 2016 at 15:52 | comment | added | Jonah |
To clarify, if you are using a mock, all you can do is assert that a method on that mock was called, perhaps with some specific parameter. You cannot assert on the state of the mock afterwards. So if you want to make assertions on the state of the database after calling the method under test, as in myDataStore.containsPerson('Joe'), you have to use a functional db of some kind. Once you take that step it's no longer a unit test.
|
|
| Jun 22, 2016 at 15:13 | comment | added | hoffmale |
I assume that I can rely on having a test data store (i don't care if that's a real or a mock one) and that everything works as set up (since I should have unit tests for those cases already). The only thing the test wants to test is that savePeople() actually adds those people to whatever data store you provide as long as that data store implements the expected interface. An integration test would be, for example, checking that my database wrapper actually does the right database calls for a method call.
|
|
| Jun 22, 2016 at 14:06 | comment | added | Jonah |
The problem is that as soon as you write myDataStore.containsPerson('Joe') you are assuming the existence of a functional test database. Once you do that, you are writing an integration test and not a unit test.
|
|
| Jun 22, 2016 at 13:21 | history | edited | hoffmale | CC BY-SA 3.0 |
added a bit of formatting, clarified a sentence
|
| Jun 22, 2016 at 12:37 | review | First posts | |||
| Jul 1, 2016 at 23:07 | |||||
| Jun 22, 2016 at 12:36 | history | answered | hoffmale | CC BY-SA 3.0 |