TDD & JIT

A while back (actually quite a while back :-) I did a couple of posts on Just In Time (JIT) and the software process.

In manufacturing, JIT exposes problems. Early discovery means action can be taken to prevent costly systemic failures when conditions change, or are no longer favorable. Thus any part of the process which helps in getting the bad news early is a JIT process.

I am currently reading Test Driven Development for Embedded C.

Test Driven Development (TDD) require tests to be written first. They do not have to be complete. Nor are they written on tablets of stone. But they do have to be written before writing code. And code does not have to wait till all the tests are written. Write one small test. Code a dummy implementation that should fail. Watch the test fail. Then write just enough code for the test to pass. If a "What-if" (or, as some developers in the Tools BU of acmet called them - "Please Consider") strikes you - as inevitably it will - first encapsulate it in a test. Then - and only then - write the code. Keep a note. But no coding.

Coding without the tests is building inventory.

And it is not just that one test that has just been coded that is tested for. All tests must pass every time a test is done. That necessitates automated builds and test harnesses. So if anything breaks the bad news is known straight away.

TDD is JIT.