[wp-hackers] Unit Testing, Yet Another Discussion

[Jacob Santos]

Characterizations Tests

"...tests that characterize the actual behavior of a piece of code. In 
other words, they don’t check what the code is supposed to do, as 
specification tests do, but what the code actually and currently does." 
(http://www.artima.com/weblogs/viewpost.jsp?thread=198296)

I would say that it matches WordPress extremely well. Therefore, I 
propose that Unit Testing be developed for the functions that have no 
external module dependencies, an example would be that plugins.php is 
unit tested, but posts.php is not. Acceptance Tests for testing web 
pages and finally Characterizations tests for functions with dependencies.

If completed, regressions and future bugs will be testable, with a 
better chance of not reoccurring.

Jacob Santos

Sam Angove wrote:
> On 8/3/07, Jacob Santos <jacobsantos at branson.com> wrote:
>   
>> If you start out with the most difficult, then yeah, it will be depressing and
>> the more depressing something is, the easier it is to give up.
>> Preventing regressions in return values, is my main concern and
>> something that should be prevented by unit testing, both the easy and
>> more difficult functions (which are more likely to be updated).
>>     
>
> I don't want to give the wrong impression: I really, really want to
> see automated tests for WordPress, and I'm glad to see someone doing
> it.
>
> It's not just a matter of difficulty, though. Proper unit-testing
> means that units are tested in isolation, with mock objects etc.
> substituting for other components.
>
> The problem with this approach in WordPress is that it uses mostly
> functions, not classes. If `foo()` and `bar()` are in the same file,
> and `foo()` calls `bar()`, you can't use a dummy version of `bar()`.
> If `bar()` calls `baz()` and ten of its closest friends, you can't use
> dummy versions of any of them. Or, rather, you can, but you end up
> with a harness that's ten times more complicated than WordPress is.
>
> It's difficult, *and* it reduces agility, *and* it increases
> maintenance costs -- the tradeoff isn't worth it.
>
> The alternative is to test the functions as a group, which is really
> closer to functional testing... It should still catch (some?)
> regressions, and having stable, tested interfaces would make it safer
> to refactor "difficult" functions into a form more amenable to smaller
> units. I gave up on *that* because the only way I could see to do it
> properly required more up-front work building the harness than my
> limited interest allowed. YMM(hopefully!)V.
>
>
>   
>> If enough people
>> get started then it will be easier for others to add, modify and improve
>> upon existing tests. [...]
>> I'll be back with any results and post all unit tests that I complete.
>> At least in the future there will be something.
>>     
>
> If you set up an open repository somewhere (Google Code?), I'm happy
> to pitch in -- at the very least I can convert my existing formatting
> tests to whatever framework you're using.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>