TDD and Embedded Programming

Michael Conners wrote:

 

in order for things to be testable, they have to be decoupled.

and

Andy Clark wrote:

 

It makes you think more about what you are trying to achieve

These are two slightly different aspects of the same very important message:

If you don't know where you want to go, you probably won't get there.  Or, in SoftEng speak, know your requirements.

Moreover, you need to know your requirements at every stage and in every iteration of the development process (regardless of which methodology you are using officially or unofficially), and hand-waved requirements in the back of your mind are absolutely not adequate --- that approach will get you into a tangle very rapidly even on one-person projects.  Software is far too complex to be created by the seat of your pants unless it's very trivial indeed.

Any form of TDD will help you to know where you want to go because it is documenting requirements (as executable tests), and as Michael mentioned, the need to test your code will drive you towards creating modular, cohesive, and strongly decoupled subunits.  This assumes of course that you embrace testing strongly and honestly and don't just pay it lip service --- it pays back value in proportion to the time invested in it.  What's more, and this is extremely important for almost every project under the sun, executable tests allow you to perform regression testing automatically.  This helps immensely not only during hour-to-hour development as updated modules are checked in, but even more so when it's a long-lived project and understanding how older parts work ends up being forgotten because old personnel have left or simply because of the mists of time.  The tests won't forget.

Unfortunately there is a fly in the ointment.  Testing is limited by extent of test coverage and by intrinsic observability and testability of what you want to test.  Full test coverage of non-trivial software systems is generally not possible, because the state space of even quite small software systems tends to be vastly beyond the capability of current-day computers to examine and test fully in reasonable time.  As a result, developers have to pick and choose what to test carefully, and it's a delicate balance that is aided by experience but never fully understood.  Theory doesn't help much in this area, because "what's important" is a semantic issue that CompSci is rather powerless to address.  My suggestion:  add semantic information to your tests so that explanations appear in your regression fault logs.  Then when things fail during regression testing, some of the thinking in the designer's mind will appear in the logs, which helps a huge amount by persisting old understanding and triggering the memory of it.

TDD *can* be an excuse for not thinking about and documenting your requirements and design, but it can also be a very effective means of capturing requirements and design details in executable code which can be invaluable.  As in so many areas, an expert craftsman will produce an expert job while a poor one will produce a mess, whatever tools they are given.  The blame for delivering a poor product can't fall on TDD (nor on any other methodology), only on people who use their tools poorly.

Morgaine.

Morgaine is correct.

Until you vet all of your requirements and determine what you need to test and what values you need to measure, you are not ready to build anything.

Requirements analysis and test planning are concurrent activities.  They must both be completed before you begin to design your system.

You need the testable data to determine if you use hardware or software techniques for implementation.

Your design establishes the needed performance for each of your HW and SW components.

These issues are at the heart of TDD.  Once you know explicitly what you need to do, you have a much better chance of a successful project.

Unless you really like to spend long hours testing, rewrite, rebuild, testing, ...

Never liked that approach myself, that is why I quickly learned structured design methods.  They do work.  They also free up your weekends for other things.

DAB

.

I suggest that this thread be moved out of Top Members and into some area where it's more directly on topic and is available to everyone, for example the Embedded Group.

Morgaine.

DAB wrote:

 

Requirements analysis and test planning are concurrent activities.

That's a very good way of expressing it.

I would add that they are interdependent activities, because a requirement that is not testable cannot be known to have been achieved, and it is also at risk of damage in subsequent development.  The two activities have a very intimate relationship.  Treating them as separate (for example, one party setting requirements without involving the test writers) is a recipe for failure.

Morgaine.

Good idea, Morgaine.

I'll move it over.