I totally agree with this. I personally do not use unit tests at all.
Why? Because I do assert-driven testing. My test code is integrated into the actual business logic. So no need to contrive scenarios.
Why? Because I do assert-driven testing. My test code is integrated into the actual business logic. So no need to contrive scenarios.
That's totally different from an organisation that doesn't do tests at all (yes they exist).
so maybe the takeaway is if people don't do what you expect, maybe digging a little deeper before running away screaming ;)
of course, asserts should not crash the app once it's in production. instead they should be channeled to a log that gets sent back to the production support team for analysis.
but during development, I'd say crashing during small errors is a great thing.
A simple example can be done by writing a single function in the root scope or some global function (javascript)
function assert(assertion, description) { if(!assertion) { console.log(description); //could also have other application error handling code } }
Then in a function in your application:
function myFunc() { var x = 1; assert(x == 1, "x does not equal 1 in myFunc()“);
\\Continue code... }
This is obviously a very simple example and can definitely be iterated upon, but it gets the basic point across and I'm on my phone so writing code isn't the easiest :-P
Some systems have something like this built in, such as node which has more features.
so I'm not saying there are no scenarios, but they all end up being the customer facing scenarios, and verifying those meet expectations. Also just developers making sure the functionality "works" naturally catches the technical bugs (because asserts in production code would cause the app to crash)
You might also want to explore QuickCheck, which helps to generate these scenarios.