[wp-hackers] Unit Testing, Yet Another Discussion

[jacobsantos at branson.com]

Thanks,

I believe I will place the unit tests up on a subversion repository, if 
you are interested. However, it is highly likely that it won't be 
Google. It isn't that I don't like Google Code, well actually it is. I 
just don't like how the interface works. I'll set it up this weekend and 
finish up some more unit tests. My direction now will be to unit test 
the simple functions that have no or minimal dependencies on other 
WordPress functions first (see below). And complete one or two 
acceptance tests (will contact the other guy and see if I could use his 
and convert it to PHPUnit with Selenium).

To be honest, I have no experience with Mock Objects and the concept 
does not make sense to me. Dealing with live data when testing seems to 
be the most logical approach to testing bugs and regressions. I can 
create the perfect world and fudge results using Mock Objects, but once 
I subject the code to live environment, I doubt the results would be the 
same in 100% of test cases. While it might be more accurate and true to 
the Unit Testing and TDD paradigm, I'm not concern with that at the 
moment. If I had to be true to it, then yes, I would give up just the same.

I did however, create a mock function and object for wpdb, but only 
until I include wpdb.php and then the mock function will be useless. The 
way I have PHPUnit set up now, I'm running off of an AllTests that will 
include acceptance tests and includes all of the unit tests.

You are very helpful. Well, I'm doing what I usually do with classes. 
Perhaps, I'm not doing the unit testing right when I'm doing it with 
classes. The way I'm isolating the functions is by testing the functions 
that the other functions calls. If the function is unit tested and it is 
called from within another function, you can make the assumption that if 
the first function passes and the second does not, then the problem is 
associated with the second function (barring that the second function 
does not use any other function from inside of it).

Another way to isolate that I've done, is to copy the contents of the 
function or method and place inside the testing method and call 
assertions. More for TDD development, but I've found it is useful when 
you don't know the work flow and need to find where the problem is.

Really, the reason I'm doing this is to learn more about TDD, unit 
testing, functional testing and acceptance testing. The second reason, 
is that even if you happened to refactor what is inside the functions to 
classes, you will still need to maintain backwards compatibility. If you 
have unit tests or functional tests for the functions, then you can 
maintain that what you are doing is not going to drastically affect 
backwards compatibility. Hopefully, if you can prove that nothing 
breaks, then you should be able to convince the core developers that the 
class method should and can be used alongside the functions.

I do not know what your goals were (are), but mine is basically 
rewriting WordPress to be completely OO and only use PHP 5.2+. My 
current classes and the WordPress classes are unit tested in that 
system, (however I'm not finished with the Plugin Model and I've not 
concerned myself with the cache class).

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