[Tutor] Learning to program, not code.
alan.gauld at btinternet.com
Sun Dec 21 19:59:17 CET 2014
On 21/12/14 09:21, Albert-Jan Roskam wrote:
> Don't postpone writing unittests (don't use doctest).
But do wait till you know what you will be testing.
You can't write a unit test until you have a unit in mind.
The OP seems to be struggling to figure out what units
he needs. Once he has done that, unit testing can be
included as part of the normal discipline of writing code.
But you need to know the structure before you get to
But even with system testing the first challenge is
still to understand what it is you are trying to build.
Until you understand the problem you can't deliver
a solution nor can you test if the solution is correct.
> They really give you focus and confidence (peace of mind!).
Often misplaced! Remember that unit tests only test units,
you also need system tests and very few unit testing
frameworks are any good at that. And especially where GUI
front ends are used. There are UI testing frameworks and
they help, but the real challenges in testing any system
are the test data build and the timing and synchronising
of the tests. Of course, system testing should never,
ideally, be done by the programmers who wrote the code,
but "ideally" often isn't possible...
> If you also use version control, you can automatically
> run all tests before each commit.
In theory yes, but if it's a big system that may not be
practical. retesting 10,000+ files takes a long time
even on modern computers. Now I doubt if many readers
of this list are working on 10000 file codebases but
you need to bear in mind that some day you may be and
these *rules* don't always apply. I've worked on systems
where running a full build/test cycle took 3 to 4 days.
It was usually done over the weekend and Mondays and
Tuesdays were reserved for bug fixing. The aim being
to have a new working system every Wednesday morning.
Author of the Learn to Program web site
Follow my photo-blog on Flickr at:
More information about the Tutor