The subject of testing seems to be in the air at the moment - Matt Stephens recently discussed it in his "Agile" column entitled "Don't unit test GUIs". This month in the Java column we are also going to look at testing, but this time from the viewpoint of design. Software design, in some ways, is a particularly strange art. The …
This Looks Like a Call for a Standard Test Harness.
I'm not sure I understand exactly how this is different from the way I've always designed software. I pretty much HAVE to have a test harness in order to develop engine functionality. The harness is usually designed to bang it about quite a bit more than in normal deployment.
All the Best Programmers, Self Medicate/Meditate and know XXXXactly where they are Going and where the Code can take you. IT is the very Essence of Being for All of the Best Programmers/Code Phreak Units.
That way is the Code written FailSafe and HindSight Secured in ITs ForeSight/HyperVision.
Yes, this is good practice
It's not new, but it's not observed/used as widely as it should be -- something it has in common with most good practice in the software industry.
Designing for testing helps to make people consider dependencies, which tends to make for better, more maintainable software in itself. XP mandates design for testing (and doesn't do Big Design Up Front) as interfaces are designed as part of writing tests.
This is why architects are called post-technical
For if you design your code like this you should be condemned to a life of conference calls, and serial status meetings.
I'm sure the author is progressing apace on the glittering crystal ladder at Accenture - or is it Atos?
Just because you can write some crappy UML for some crappy EJB doesn't mean you should... CalculatorBean? CalculatorProcessor?, CalculatorProcessorFactory? afterPropertiesSet? Here be madness.