[Tutor] Integrating TDD into my current project work-flows

[Mark Lawrence]

On 06/05/2015 00:16, WolfRage wrote:
> On 05/05/2015 06:49 PM, Alan Gauld wrote:
> <SNIP>
>> Not better, just necessary. The two concepts are complementary.
>> You need both. The developer primarily needs unit testing, the
>> integrator*(who may of course be the developer in a different
>> role) needs integration testing and the client/project manager
>> needs system testing and acceptance testing. They are all part
>> of a project (especially big/commercial projects)
> So how low level of unit testing is acceptable. My use case is the sole
> programmer on a team project. Their is potential for another programmer
> to join the ranks but that has not happened yet. Additionally the
> project is well under way. But Feature additions have slowed so I want
> to make the code less buggy, and so I am hoping to re-factor my code
> now. I think some unit tests could improve the end result of my
> re-factoring, but where to start is the toughest problem for me to
> solve. Especially given the time trade off that is at least initially
> required for unit tests.
> <SNIP>
>>
>> Don't underestimate the scale of testing. It is not unusual to
>> have more test code than functional code! (although it is still
>> the exception!) In real-world commercial projects testing (and
>> the associated debugging) typically consumes about 25-40% of
>> the total project budget. Baseline coding by contrast is only
>> about 10-25%, sometimes much less.
> I agree I have seen this sort of budget numbers in the government
> project that I have been involved in. Especially once the project hits a
> more general life cycle/maintenance mode.

If and only if the project ever gets this far.  One third of major 
projects fail to deliver anything.  Part of the reason for that is 
growing bug lists owing to limited or even no (controlled) testing.

>
> So how can I make unit testing apply to my project without starting from
> scratch? And how low should I test(ie. every function; every class;
> every interface; system level)?
> Thank you for any insight and all of your help.
>

Ensure that every publicly available part of your code is tested.  Don't 
bother with internal helper functions or similar.  Remember that the 
toughest parts to test are often the error handling capabilities and the 
rarely occurring edge cases, so up front thought can save a huge amount 
of time, money and effort later on.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence