[wp-hackers] Unit Testing, Yet Another Discussion
jacobsantos at branson.com
jacobsantos at branson.com
Fri Aug 3 13:55:56 GMT 2007
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).
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'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
More information about the wp-hackers