[kwlug-disc] Balancing Unit and Functional testing

[Mikalai Birukou]

Following yesterday's talk about code about testing.


Can we say that if particular external requirement stays long enough, 
then requirement-describing functional test is a must?

In this light some functional tests have a place from a very startup of 
a project: they will outlive all versions of code that provide 
implementation. And no unit test may seem worth an effort at a startup 
phase, unless it is a help for writing code.


"No bugs" is a non-specific external functional requirement.

Reproduction of conditions with bugs in functional tests is a way to 
make "no bugs" specific and tangible, and in a helpful way: "Hey, that 
is a bug. We need no bugs."

Fuzzing as a functional test makes "no bugs" tangible. It also has a 
security aspect to it.


When your colleague is miss-using function, it is fuzzing. There more 
understandable errors are, the more directing errors are, the less time 
will be spent by inevitably lazy everyone(?). Comes to mind this 
https://www.youtube.com/watch?v=eL5o4PFuxTY

Professional laziness is recognizing that your fellow developer is lazy, 
and you must help them in your code (they write their code anyway!).


Yes! Here is a case for Rust. Just hear it.

We wanna fuzz, ensuring all cases are covered. But we are lazy to write 
code, and tests are code. So, how about compiler that forces you to 
attend every branch in Result<_, Enum<Err1,...,ErrN>>.

No one forces lazy Joe to write unit tests, but he has to make code that 
compiles. It's not us, it's compiler's requirement :) .

You can explicitly leave todo!/unimplemented!/panic! to skim ahead. But 
this is explicit and is searchable. With explicit approach code base 
stops being a minefield, creating a safer environment. Also, it's just 
honest to recognize places where you are lazy.