I really prefer being able to write some app code, and then immediately be able to run it by a test so I feel confident that it’s working, before I go piling on more code that depends on it. I want to code confidently, with less uncertainty. Testing as I code (whether I test a little, then code a little, or the other way around) keeps me on task and helps keep me from getting sidetracked off into a bunch of areas of my project at once.
If I’m going through a mechanical process of refreshing the browser, entering input, submitting it, watch and see if it breaks, rinse, repeat, I feel like I’m doing a computer’s job. Relying only on this method for testing feels barbaric, plus it takes me out of the flow of development and gets me all frazzly in the brain.
Some months back I started using Zend Framework for a while, and this was an area I happened to be interested in. I wanted to try to apply this workflow while working on a ZF app, but I had trouble when it came to setting up mocks or fixtures for unit tests, and managing a test database and resetting it to a particular state for each test. It seemed like a lot of extra heavy lifting to come up with my own solutions for these things. (Nowadays, it doesn’t seem quite as daunting, but still.) Then i was away from ZF for a while, did a little bit of Rails stuff, and now I’m back doing PHP stuff again.
This time, going along with others in the outfit I work at, I got started with a certain (ahem)other framework. And I am experiencing some real pain in getting unit test cases to work properly in it. Lots of errors caused by what seems to be buggy behavior where the fixture runner fails to get the database tables set up and torn down at the right times. Also, come to find out this framework’s testing facilities are built on a testing framework that hasn’t seen an update in like a couple-three years. Also, the conventions for how a test case or fixture needs to be coded for it seem to be in constant flux, and often inconsistent, and the relevant documentation is considerably behind the curve. Then again, this is all in reference to what is supposedly only a “release candidate” version – though it’s the version everyone seems to be using now, and most help you can dig up online has to do with this new version. Here’s a thought: you can call something a “release candidate” all you want, but if you’re putting it out there for people to download and use, I’d say that constitutes a release. I don’t know what dictionary you found the word “release” in, but that’s my interpretation – though it does mean you have less of an excuse to put out buggy shit.
Nobody in a certain IRC channel seems to have much of any help to say on the subject, as the usual perspective of other users in there seems to be “Gee, I’ve never really managed to get that whole testing thing going, it’s hard” (these being PHP people, after all).
Also, it’s perhaps illustrative to note that the framework itself comes with a whole bunch of built-in test suites for the framework core itself, and tons of those fail and throw errors all over the place, including the same kind of errors I’m having problems with, and many for features that I’ve found out aren’t finished yet – don’t these geniuses know how to mark a test to be skipped? My joke is that they leave them there to lure unsuspecting noobs to the IRC channel to give the cool-kids’ table that frequents it someone to practice their snarky one-liners and alpha-open-source-dev “if it’s broke, fix it yo’ damn self” retorts on.
Anyway, the result is basically two days wasted trying to get the most trivial of test cases to run for two models with one association between them – and I’m not even trying to test the association.
It’s been said that Rails supports agile practices such as TDD; as an opposite of “agile,” I’d say this other framework currently supports klutzy practices, such as, don’t bother writing tests, you won’t be able to get them to run anyway.
But enough rant. This experience has left a sufficiently bad taste in my mouth to turn my attention toward Zend Framework again. I’ve heard some very encouraging things about testing and fixture facilities for ZF, some of it from the general direction of Matt O’Phinney, who I seem to remember having stopped by this blog once or twice in the past, and who seems like a much nicer dude than those Cake cats.
Alternately, I’ve realized that ZF is enough of a loose and flexible framework, in large part because it doesn’t rely on automation and code generation as heavily as Cake or Rails, that you can pretty much add anything to it that it lacks, or in the unlikely event that something in it turns out to be broken (highly unlikely given the quality of work that seems to prevail in it, but that’s what corporate sponsorship will get you), or even just doesn’t do quite exactly what you’re looking for, it’s no trouble to swap it out for something of your own creation. I could in all likelihood come up with my own simple fixture runner, and perhaps even migrations as well, if I’m willing to put in the time, and get it working with ZF just fine. ZF is a “framework” in the classic sense of the word that was common before Rails made people expect a lot of magic: a class library for a certain category of functionality, made up of various stuff designed to work well together. That’s the thing I liked about it when I first got into it, and I still like that about it.
Anyone out there have some experiences you care to relate in trying to be TDD or even at least semi-TDD with ZF? Tried Zend_Test? Found or written a good fixtures solution?
Update: my exact problem, found here. It’s not hard to see why I’m frustrated, what with all the differing and inconsistent information out there about how to write a model test, most of which seem not to work with the newest version, despite its documentation still showing the non-working old version’s method. I’m going to try mcurry’s example of a properly working model test and fixture – if that doesn’t work, I’m done pulling my hair out and I’m either switching to ZF or winging it without tests.