I would like to hear some words of wisdom from either your guys personal experience or maybe opined by by the gurus about whether or not to use random data in unit tests.<p>On the one hand, I understand the argument that random data makes your test irreproducible; so if something breaks the test, it make take a while to figure out exactly what and why went wrong.<p>On the other hand, I feel that hard-coding test data is too restrictive. For example, in the linked video, they have a 40-hour week with a 8 dollars per hour rate, and they expect the result of the calculation to equal 320. An immediate question arises, what's so special about these numbers? Would the test pass if the input were different? What about a 38-hour week and 20 dollars per hour? And so on...<p>What's your take on this?
If anybody is interested, this appears to be part of a series: <a href="https://www.youtube.com/watch?v=5LOdKDqdWYU&list=PLlmVY7qtgT_lkbrk9iZNizp978mVzpBKl" rel="nofollow">https://www.youtube.com/watch?v=5LOdKDqdWYU&list=PLlmVY7qtgT...</a>
Specific tests doesn't exactly mean "Simple" tests. It is hard to balance between the two but from my experience when people try want to write specific tests they just start writing extremely simple tests.
They seem to start talking about stacks and leaves of stacks, as if one should only test at leaves. Surely this is woefully inaccurate?<p>Isn't the point of tests to test behaviour? Sure be specific about behaviour. And sure, unit tests should not overlap too much, but this is a separate matter to multiple tests failing, and now I don't know where my bug is.<p>?
This is also important for system, integration, e2e or any other complex test.<p>The problem is that it is very hard to filter out failures due to environment or other unrelated issues, and even harder to pinpoint the problem
I rather prefer higher level tests (Integration tests?) that says, hey, you have an error. Or user will experience error. Or the expected high-level outcome is wrong.<p>Because with unit testing, I miss and can miss so much conditions. If I have high level error, sure, I will figure it out - but it is part of development process rather than something breaks live and then you have to figure that out anyway.<p>Ofcourse Unit tests have their place where I want to test that this input produces particular output (for example some parser, sanitizer class etc.) and I want to receive a signal when my future development breaks some stuff.<p>Tldr: I don't think that having a very specific "what went wrong" is that important. I'm grateful when tests fail, because that saves me from mistakes going into production. It's like a safety net.