A function that has the name “hasValues” has an expected behaviour. It will tell me if the calling structure or object will contain the values in parameters. Whereas, a function called “andValues” means absolutely nothing.

So yes, you get a pretty english sentence, but you lose the meaning of what you’re doing. So in the context of your little sentence, it works fine, but in the greater context, in the next lines of code, a function “andValues” has “little value”.

brem

i) It’s an extra API on top of the existing test framework’s. You don’t have to use it if you don’t want to, but the intention is to get more compact and less cryptic code.

ii) Perhaps it looks clumsy. My criterion is that it takes less time to understand the code if you haven’t read it in the last month and need to update it.

iii) Any understandable API needs to use words in some natural language. English is just the usual choice. I’m just discussing the principles. If you want to use words from German, Esperanto or Buganda, the principles are the same.

I see your point, but I have so many objections to so-called “fluent” interfaces that I never know where to start. Please take none of this personally!

i) I already know PHP and – for example – xUnit, why do I have to learn your own hand-rolled language simply to maintain your code?

ii) “Fluent” interfaces _never_ read like fluent English. They, without exception, read like a clumsy, uncomfortable hybrid of English and whatever programming language is in use.

iii) If the interface did manage to read like English…how does that help the millions of people that are fluent in, say, PHP but don’t think in English in the first place?

@Ilja: Of course you could have a full-blown DSL, but it’s more work to implement.

@zilenCe: I haven’t designed this in detail, and I might want to do it differently after thinking more about it. Still, I don’t think you would have to add an extra call at the end. The chain would involve the object generated by the assertThat() call. $this, the test case, would receive the final result and be able to check the assertion.

You say that assertTrue and assertFalse are easy to use. Of course, but they are unable to express anything complex. Which is what I’m trying to do here.

Also, considering that most methods have simplified names where you can interpret a lot of stuff into them you may end up having a unit-test class with several hundred methods (noone can remember that). Using assertTrue and assertFalse is much easier than having ->hasValue(false) ->isFalse ->isNotTrue ->isNotFalse ->isTrue ->isTheValueIWant(false) just to create easier “sentences”.

$this->assertThat(
$form->hasSelect(
withName(’statusConfirm’)
)->hasValues(),
array(‘Yes’,'No’)
);

This format actually makes it more dificult for me to count the references – something I do automatically when reading code.

If you want a DSL, then you might as well make it a full blown DSL, like SQL:

$this->assert( ‘FORM HAS SELECT ( WITHNAME “statusConfirm” AND HASVALUES (“Yes”, “No”) )’ );