So you do do tests, just not specifically separate unittests.

That's totally different from an organisation that doesn't do tests at all (yes they exist).

yes, but if someone asks me in an interview if we do unit testing, the answer is really a no...

so maybe the takeaway is if people don't do what you expect, maybe digging a little deeper before running away screaming ;)

Without scenarios, how do you run your code before it goes into production?

i use the combination of assert-driven development + UI/UX testing. (manual, but that could be a valid candidate for automation in my projects)

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 be interested in `contracts' which are basically assertions on steroids. See https://en.wikipedia.org/wiki/Design_by_contract (or http://blog.racket-lang.org/2012/11/contracts-for-object-ori...) for an introduction.

You might also want to explore QuickCheck, which helps to generate these scenarios.

Could you expand on what you mean by assert-driven testing? I'm not finding any good explanations from a Google search. Sounds interesting.

My GUESS was that he/she means that the code has asserts in it that check if something is not right at runtime. I personally would not call that a replacement/alternative for unit tests. In fact, it may be counterproductive ... a small error in the code would bring down and entire application.

i would counter this by saying that a small error in code SHOULD bring down the entire application.... during development. otherwise the error is not visible to developers when they can best/easiest fix it.

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.

Assert driven testing means that the tests are part of the actual code that is running. It's helpful because when an assert fails, the stack trace is right at the position where it failed. In many ways it's an easy way to incorporate testing into your application without the need for an additional framework.

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.

http://nodejs.org/api/assert.html

Sounds like Design by Contract.

i think that's right, but maybe more "agile" in that there is no explicit contract being fulfilled, just what the developer ensuring valid input and output to the functions they implement.