The thing with unit testing is if you use it you almost have to do TDD then, otherwise it's sort of hypocritical. And to do unit testing/TDD correctly you'll have at a min about 4 tests per unit.

I dont get that -- unit testing was around for decades before the TDD methodoligy appeared. What's hypocritical about writing tests after you write code?

As for the number of tests, 4 seems pretty arbitrary..? In my engine, the internal assertion macro is hooked up to the testing framework, so I just write one test per 'unit' that calls all methods / demonstrates each usage, and asserts he results are as expected. If these test assertions or the units internal assertions fail, the test fails.

Like in TDD, I hook my tests up to the compile button, so a test failure is reported the same as a compilation failure (with file/line numbers), but I usually write them after the code, or concurrently, instead of before like in TDD.

This means you are bouncing back and forth from your test project to your production project about every 30 seconds to a min. Some tests you might have to stop and think about what you want to write.

There's no reason you can't write your tests in the same source file as the unit if you feel like it ;P
As above, a IMHO a large part of your tests should be taken care of by assertions that are internal to the unit anyway, and not part of the test.

The point of TDD is that it makes you stop and think about the use case (what to write for the unit) before writing anything, but often this is true anyway. E.g. You're writing some code that requires a hash-map lookup, but you don't have a hash-map class (for some odd reason) - at that point, you've already got a production use-case for what the hash-map class is required to do, much like what your TDD code would give you.

"QA hours are cheap."

Tell that to the people I used to contract for.

Depends on what is being tested, etc...

I usually had more programming expertise than most of the people doing the programming (I also used to fix code produced by others, dealt with things they forgot/ignored/never knew to do)

Sloppy companies dont have the programmers test their own code first and foremost (a practical problem also because many programmers have never learned how to do it properly). Even things like code review get skpped.

Ive also worked for companies who WANTED automated testing, but for much of the products development the code kept changing faster than the automation team could keep up (and the product programmers and their managers often were not cooperative in putting features into the code itself to facilitate testing).

Often it was so bad that I could find vast quantities of bugs faster than whole teams of programmers could fix them (assuming they werent already busy writing MORE buggy code/features)

I guess, at the end of the day, it's all about how sloppy the individual programmer (or the company that he/she is working for) is. Different tests for different situations, but the important thing is that you don't let code slip by untested? Sounds about right.

I guess, at the end of the day, it's all about how sloppy the individual programmer (or the company that he/she is working for) is. Different tests for different situations, but the important thing is that you don't let code slip by untested? Sounds about right.

Lack of testing is often just one problem. Getting the managers to prioritize a bug (or even except it is a bug) so that it actually gets fixed is another fight. More than a few times a user interface bug I found and reported (and demonstrated) was then subsequently ignored (sometimes I was told "the customer wont do that") and quite soon after the customers started using it they were reporting the problem.

Long ago a QA manager told our QA group that there is a psychological impairment to QAs effectiveness (first and foremost is funding/prioritization and then cooperation) -- that there is a big negative aspect because the result of our work is to tell the programmers (and often designers) that their code/design is crap. So many times, Ive had to show them their code was buggy - actually demonstrate it before their eyes before they HAD to believe that THEIR code had a problem.

In addition, some of the most iconic features found in games are made from unintended bugs. Would be a shame if an automated system just fixed the bug that later became the Creeper in Minecraft, without considering its potential use in that game.