Starting small, driven by tests
Developers have a habit of thinking in terms of technical composition
of systems rather than functional terms. For example, reading the
spec, some of you will have been thinking “well, that’s obviously an
RTOS task, and I need to implement an ISR for that other thing, and
then there’s an FSM implementation I need to do…and…”.
And that’s OK.
What we’re going to suggest here is a little different, though: focus
on very small slices of functionality, write a series of small tests
for these, and implement the code incrementally.
A small slice : door handling
This is probably the simplest functional slice that you can tackle in
the system. Ignore everything else. Pretend the rest of the spec
doesn’t even exist. The entire scope that you have to implement is
this, and nothing more:
- There is something called a door, and it has a specific job to do.
- The user can request that the door open or close by sliding a switch
back and forth. That switch belongs to the door.
- The door can read the switch, and see whether it’s in a high or low
- It’s up to the door to decide whether or not it should actually be
physically opened. The user is just making a request, not giving an
order. The door is in charge.
- Other things are interested in whether the door opens or closes, so
it needs to inform something. We don’t need to know or care what
will happen when we do this, only that it has to happen.
- If it’s OK to open the door, the door cause an actuator to operate,
and this physically opens the door - it does this by setting high or
low on another pin.
- Sometimes the door gets told that it’s not allowed to be opened.
- If the door isn’t allowed to be opened, it will never operate the
actuator. The user can slide that switch back and forward as much as
they like, but they get ignored.
A possible test list for the door
Other functional slices to consider