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.

I’d finally got fed up with this behavior, and just last night got a helpful hint about it in #emacs on freenode (I’ve forgotten your nick, but thank you, if you read this).

The problem is, when you end a line with a paren still open, and continue your code on the next line, most of the cc-mode indentation styles consider this an “unfinished argument list” and specify to indent the next line over to the column just to the right of that open paren. This looks fine in C and its ilk – the idea is that you’re probably doing this because you have a function with a lot of parameters, so it keeps your arguments (or parameters) all lined up together like they’re in a list. You see this sort of thing in Ada code quite a bit too, I think.

Where this really falls down though, is when you’re coding PHP. In PHP you do a lot of literal associative arrays in your code – stuff like this: $expected = array( 'id' => 1, 'last_name' => 'Jones', 'first_name' => 'Robert', 'middle_inital' => 'F', 'ssn' => '999-99-9999', 'dob' => '1978-12-17');

In this case, the whole reason I’m continuing the contents of the array on a new line is because I don’t want the line to be super ugly long. If I’d wanted this stuff indented way over by the opening paren of “array(“, I wouldn’t have put in a new line in the first place. To make matters worse, sure you can go back over and delete that extra whitespace and indent it where you want, but once you add to or edit that line again, emacs very rudely shoves it back over where it wants it.

Without going into a whole tutorial on how emacs defines indentation rules (which I’m not at all qualified to do, but seems fascinating), you can redefine an indent rule by putting your cursor in the spot where the offending rule is taking place and hit C-c C-o to see what “context” emacs considers it. Hit return to change the setting for that context, and you’ll be asked to enter a new setting using some little syntax of symbols that emacs uses. I don’t know them all, but I have figured out that “0” means “don’t indent at all” and “+” means “indent one level” (where the amount of indentation for a level is defined by the c-basic-offset variable). + is the one I wanted.

I will note, however, that it’s sensitive to how many sets of parens you have open, so if you end a line two open-parens deep, that next line will be indented twice. For example: $this->assertFalse($this->_validatesWith($original, array('last_name' => '')), "Last name should be required"); But I can live with that.

Of course you don’t want to have to do this dance every time you open a PHP file, so you’ll want to put it in your .emacs or .emacs.d/init.el somewhere. In case you haven’t run across this yet, after performing most actions in emacs you can hit C-x ESC ESC to see the elisp code for what you just did in your minibuffer (where you can also edit and re-run it if you like.) In this case, the elisp code it gave me was:

(c-set-offset (quote arglist-cont-nonempty) (quote +) nil) ; alternately, using ' as shortcut for quote: (c-set-offset 'arglist-cont-nonempty '+ nil)

If you also do a bit of C programming, you may want to only have this affect PHP files, in which case, slap it in a mode-hook.

You can also set the size of indentation, and things like whether you want tabs or spaces, and what kind of indentation/brace style you prefer (check out M-x c-set-style to experiment a bit – I’m a k&r man, myself) but you should be able to google up the same stuff I did for that.

Says the guy using a PHP blogging engine :P Then again, have you seen its spiffy AJAXy new UI?

One of the problems in this, besides being a lame excuse for an abstraction that probably doesn’t need to exist anyway, is PHP’s noisy syntax (link only somewhat tangentially relevant). I get so sick of typing “array” and “$this->” all the time. (Not being a regular Python programmer, it’s not up to me to complain about “self.”) These irritations are amplified when coding to a framework like Zend Framework or CakePHP because frameworks give you lots of helpful methods, many of which can take lots of optional behavior-modifying arguments in the form of associative arrays (hashes, for the Ruby folk.) So the code become littered with these verbose constructs that give the reader/programmer pretty much zero useful information.

Let’s start with “$this->”. Seven characters to say something that Ruby gets across in one (“@”) in the case of instance members, or doesn’t even need you to say at all, in the case of methods. (There is, of course, the case of requiring “self.” when calling a setter method, in order to distinguish it from declaring a local variable). Declaring a literal array or hash in Ruby? No need for the the pseudo-function “array,” just need a pair of square or curly brackets. A fairly direct translation of the janky finder argument from that earlier post into Ruby would probably look something like this:

{ :or => [ {'Company.name' => 'Future Holdings'},
           {'Company.name' => 'Steel Mega Works'}],
  :and => [ { :or => [ {'Company.status' => 'active'},
                       { :not =>  [{'Company.status'=> ['inactive', 'suspended']}]}
                     ]
            }
          ]
}

update: newer version of GeSHi with the newly installed WP-Syntax plugin makes this display much nicer.

Another funny thing I notice about code written for these frameworks, particularly in “scripting” languages, is how much, with all the function calls and arrays of arguments and such, the code starts to resemble Lisp. Maybe there’s just a natural tendency for code to gradually approach Lisp as it becomes more abstract. It’s not hard to imagine the Lisp version of the above – just replace the brackets with parens and get rid of the commas:

(:or (("Company.name" "Future Holdings")
      ("Company.name" "Steel Mega Works"))
 :and ((:or (("Company.status" "active")
             (:not (("Company.status"  ("inactive" "suspended"))))))))

Was just pointed out to me that today is the 40th anniversary of the historic “Mother Of All Demos,” in which Douglas Engelbart introduced, among other things, the mouse.

Enjoy the video, if you haven’t already seen it.

You know what’s annoying? Object-relational mapping.

So, I’m reading the CakePHP docs, and I some across this. Can anyone please explain to me how this:

array(
  'OR' => array(
    array('Company.name' => 'Future Holdings'),
    array('Company.name' => 'Steel Mega Works')
  ),
  'AND' => array(
    array(
      'OR'=>array(
        array('Company.status' => 'active'),
          'NOT'=>array(
            array('Company.status'=> array('inactive', 'suspended'))
          )
        )
      )
    )
  );

is an improvement/abstraction over this?:

SELECT `Company`.`id`, `Company`.`name`,
`Company`.`description`, `Company`.`location`,
`Company`.`created`, `Company`.`status`, `Company`.`size`
FROM
  `companies` AS `Company`
WHERE
  ((`Company`.`name` = 'Future Holdings')
  OR
  (`Company`.`name` = 'Steel Mega Works'))
AND
  ((`Company`.`status` = 'active')
  OR (NOT (`Company`.`status` IN ('inactive', 'suspended'))))

IMHO, ORM solutions fail when they try to do too much magic. You take something simple that any decent developer ought to be able to handle like SQL, and build a complex rats-nest of trivial string-and-array-munging operations as an “abstraction” on it. What you get is in many cases actually more difficult to use: the developer finds himself running to the framework documentation to dig up the right incantations that will yield the SQL he wants and could just as well write on his own.