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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
