Parody – a PHP testing library

by mattsah • 14 years ago

45 36 14 years ago

sentiental• 14 years ago

There are a number of mock object libraries out there (mockery, shmock, phpunit's mock syntax, etc). This just looks like another builder syntax for making mocks / stubs with some fanciness around class extension - what's the benefit?

Also, how often is it useful to define a class at test time that is initialized by production code (from the section I Still Have Serious Dependency Issues!). This seems like an unlikely use case.

mattsah15• 14 years ago

I wrote this library for two major reasons:

1) To avoid the complexity of existing frameworks. 2) To be able to quickly and easily test code with various kinds of dependencies.

It is predominately designed to test a single class in an extremely isolated context, not in the context of a full blown testing framework.

It is designed to be a stupid as possible with the intention of allowing the developer (myself) to define very strict test condition and very fine grain control.

freework• 14 years ago

I'm confused, what does this have to do with Aaron Swartz?

stanleydrew• 14 years ago

I assume you are trying to make a joke. But it's not very funny.

shanelja• 14 years ago

Not funny at all, but in all honesty, I am also keen to get back to the normal flow of things, I have paid my respects and I feel that perhaps 15 articles on the front page may have been enough for now, leave his friends to mourn as they will, if you over do anything people tire of it quickly.

Gigablah3• 14 years ago

This library could use Composer support. I suppose I'll make a quick pull request.

mattsah15• 14 years ago

I'm cool with that. Feel free to move the example.php into a separate subdirectory to make it cleaner too, but please fix the includes to point to whatever relative directory need be.

Gigablah3• 14 years ago

It's done, I didn't touch the file structure since Composer is smart enough to map classes even if the layout isn't PSR compliant.

0x07• 14 years ago

Noticing it's licensed under AGPL. I guess that means all projects that happen to include this (or something depending on it) would then be required to post full source code on the webpage, even if the project is for a single install?

mattsah15• 14 years ago

Nope. If the project actually uses tests for its function and it is accessible they would be required to provide the source to anyone user who requested it.

Much like the regular GPL, AGPL is dependent on distribution.

If you create a project that uses it to perform testing on the project, unless your testing is a function of the actual project then you wouldn't have to do anything of the sorts.

If you created a testing platform online that used it to render services, then you would, yes.

0x07• 14 years ago

Oh okay. I haven't really looked much into AGPL, I just assumed it was "infecting" the whole project sorta like the GPL.

mattsah15• 14 years ago

Let me clarify, I don't think anyone's projects that are web facing actually use their testing library to perform the tasks. So for all intents and purposes their projects as they are "distributed" over a network are not linking to it even though it may exist in their source tree.

The only exception to this would be if the project is actually for testing, like say an online service that tests your code.

Also any private non-distributed use does not require source distribution.

mattsah15• 14 years ago

GPL does not "infect" a whole project either.

GPL only requires you distribute source if you distribute the binary.

It is designed so that users maintain the right to modify software that they use.

The only difference with the Aferro clause is that it considers network use of web software to be distribution and pertains to obfuscated software (i.e. server side source) even if it's not binary.

parf73• 14 years ago

great simplistic php testing framework: https://github.com/parf/spartan-test

wvenable4• 14 years ago

Since this library requires PHP 5.4, I'm not sure why it bothers with this syntax:

    Parody\Mime::create('Vendor\Class\Project')
    -> onCall('method') -> expect('argument one') ->  give('response one')
    -> onCall('method') -> expect('argument two') -> give('response two')
    -> resolve();

When one could just use anonymous functions to give the same result with less API-as-code.

    Parody\Mime::create('Vendor\Class\Project')
    -> onCall('method', function($param) {
      if ($param == 'argument one') return 'response one';
      if ($param == 'argument two') return 'response two';
    ) -> resolve();

This is more flexible, less code for the framework, and easier to learn.

mattsah15• 14 years ago

Expectations and responses (provided by give()) are actually held internally. Your syntax is cleaner for very simple responses, however will become increasingly complex, particularly when the response itself is determined by a callback. Adding more params would clutter your example terribly. Also, the mime's are passed to callbacks which provide response so that additional functionality can be added, see this recent use-case:

Parody\Mime::create('App\Text') -> onCall('create') -> expect('WTF' . DS . 'Yo') -> give(function($mime) { return $mime -> onCall('underscorize') -> give('wtf' . DS . 'yo') -> resolve(); });

mattsah15• 14 years ago

Eww, bad formatting, apologize, as I'm not familiar with hacker news comment system, but you can see the case here:

https://github.com/dotink/inKWellToo/blob/master/external/te...

wvenable4• 14 years ago

That seems exceedingly clever -- too clever. I'd make some of that functionality a named function and call it from my callback. It took me way too long to figure out what your code did.

Parody – a PHP testing library

Related Stories