[wp-hackers] Fixing Bugs
jacobsantos at branson.com
jacobsantos at branson.com
Mon Aug 27 21:56:42 GMT 2007
Well, yeah, also it should be unit tested, along with QA. A few people
are doing so already and I am one of those people. However, the unit
tests won't be ready for the 2.3 release, or cover 100% of the
functions. Some files and functions are unit testable (but are
acceptance testable and characterization testable), which would add to
the time needed to test the API functions.
I was able to find and patch a few bugs in a plugins.php alone, which is
relatively stable. I started unit tests for taxonomy.php, but don't have
complete coverage and won't probably have it for a few weeks.
Unit tests won't completely stop bugs, unless test are written for the
bugs after the fact (which is always a good idea, to make sure that the
bug never shows up again). What I've been trying to do is test the
expected behavior (characterization tests), instead of the intended
(what the original developer thought) or morphed behavior (what happens
when you give the wrong input; garbage in, does garbage come out?).
Unit Tests won't replace manually testing WordPress features, nor would
acceptance tests when those are complete. Humans have a better odds of
finding errors where the tests don't and tests have the advantage of
being able to run so that past bugs don't show up again and make sure
humans didn't miss out an intended feature.
Some WordPress code would only be tested if someone runs that portion,
while others require manually entering data from the site.
isn't part of external libraries.
Martin at Cleaver.org wrote:
> Indeed, unless a system gets documentation, to explain and put rigour into
> the model of how it should work, bugs will continue to get through the
> On 8/27/07, jacobsantos at branson.com <jacobsantos at branson.com> wrote:
>> I like this idea, but I think it has more to do with users submitting
>> patches for bugs. Which I think is what the bug hunts are all about,
>> finding and submitting patches.
>> I also think that reasons should be given when closing as invalid or
>> wontfix. It is good bug handling in my opinion and something that won't
>> annoy those who submit bugs. Some bugs marked as won't fix or invalid
>> mean that the bug is external to the application that can't be fixed
>> easily. However, making it clear what the developers intention was would
>> go a long way.
>> There will never be any release in any application where everything
>> works. However, fixing what bugs we have now would be an awesome idea!
>> Documenting the code should go along with this idea.
>> Jacob Santos
>> Geoffrey Sneddon wrote:
>>> The number in bugs in WP has grown steadily over several years, yet
>>> the number of unfixed ones increasing quicker still. We need a release
>>> that is stable. We need a release where everything _works_. Can we
>>> have one release which includes _nothing_ but bug fixes. There are 409
>>> open bugs according to trac (and I expect there are others marked as
>>> wontfix/invalid without reason). There are some massively annoying
>>> bugs for users, not least things like being unable to use IRIs in
>>> sanitised content (#4570, target 2.4).
>>> - Geoffrey Sneddon
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
More information about the wp-hackers