Timeline for How do I really write tests without mocking/stubbing?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 25, 2020 at 5:11 | audit | First posts | |||
| Jul 25, 2020 at 5:11 | |||||
| Jul 1, 2020 at 19:54 | comment | added | FeRD | @slebetman Shhh! "What if I have to write so much code to support my unit tests that I end up accidentally implementing the rest of the system?" is, like, one of the paranoid nightmare scenarios the anti-unit-testing crowd get all spun up over. Don't feed their neuroses by validating the possibility. 😏 | |
| Jun 30, 2020 at 20:54 | comment | added | njzk2 | how do you differenciate between Fake and Stub? | |
| Jun 30, 2020 at 18:40 | comment | added | slebetman | @Flater I've seen a software implementation that started out with a "fake" db as files on disk because the team decided to defer choosing the database to later and work on the core logic. The code ended up with a very robust and well specified (at least well tested) on-disk binary file format that in the end they decided to make the "fake" real and the software just saves your data to the "fake db" which is now a file on your system. | |
| Jun 30, 2020 at 17:47 | comment | added | Gensys LTD | This approach is called "functional test" where I come from - check if the components and objects work well together to achieve a particular piece of functionality, as opposed to "unit tests" which check basic functionality ( input correctly receives and passes on input ) | |
| Jun 30, 2020 at 12:30 | comment | added | Euphoric | @Flater That is correct. The Fake should satisfy the contract in fullest, but it doesn't need to become a full implementation. It is easy to create simple implementation of 3rd party service when you don't have to worry about persistence, security, scalability, performance (as everything is in memory either way) and many other -ities that are not necessary for testing. It also makes it easy to verify if the Fake really behaves same, as it can both be reviewed and run to see it's behavior. | |
| Jun 30, 2020 at 12:08 | comment | added | occipita | @Flater - yes, fakes may well end up being at least nearly fully-featured implementations. I'm not a hard-line classicist myself, but still try to keep my use of mocks minimal, and find I often end up with fake repositories that are able to be fully functional, other than that they only store data temporarily rather than permanently. | |
| Jun 30, 2020 at 10:51 | comment | added | Flater | Wait you unit test your fakes as well? What's the point of that? Because that would mean that your fake fully satisfies the contract it is faking, at which point the fake has become a real implementation. | |
| Jun 30, 2020 at 10:37 | comment | added | Euphoric | @kibe As I explained in the answer, my definitions are different than what is traditionaly accepted. But I find my defintions have much higher value and make more sense than what the commonly accepted one. | |
| Jun 30, 2020 at 6:57 | comment | added | kibe |
a classicist himself, awesome! so, wouldn't that be an integration test? since you are using the real implementation of UserValidator and (almost) a real implementation of UserRepository?
|
|
| Jun 30, 2020 at 6:23 | history | answered | Euphoric | CC BY-SA 4.0 |