[TYPO3-core] Resolving vs. Closing bugs

Ernesto Baschny [cron IT] ernst at cron-it.de
Wed Jun 7 17:30:44 CEST 2006


Dmitry Dulepov schrieb am 07.06.2006 13:57:

>> What I meant was that running a test that the code submitter knows to
>> work proves nothing. The reason the tester must make his own test rig
>> is that he finds those cases which might have escaped the coder.
> 
> Correct. Tester's job is to check that fix works. He may do a straight
> test but may also test it in the way that developer even could not
> imagine

This is why the extreme programming [1] technique of unit tests [2] is
so much better when working on a huge project with a great amount of
people. Having this from the start is a huge benefit (e.g Gallery2), as
the workflow is then as follows:

- bug is reported
- bug can be reproduced in form of a "test-case". the test-case tells us
"failed"
- programmer fixes the bug
- programmer runs the whole test-suite again. This might also catch
side-effects of the bug fix
- programmer sees that his new test-case is now "OK", so the bug fix
worked and nothing else broke.

The testing makes basic part of the bug fixing (creating a test-case is
then the very first step you need to do before starting to fix the
bug!). This might sound a huge overload, but it keeps all future fixes
from breaking that same place again and again.

I know nobody has time to do it, but it would be cool if we could start
with a basic unit-testing framework for core-developers and then try to
create test-cases for every new bug reported. Then, if we had more time,
we could start creating some test-cases for already "stable" parts,
where we see risks that it breaks in future changes so that we can be
sure that it will never break.

Cheers,
Ernesto

[1] http://www.extremeprogramming.org/
[2] http://www.extremeprogramming.org/rules/unittests.html



More information about the TYPO3-team-core mailing list