Added unit testing skeleton with mostly stubbed server tests.

[tierra]

This is a start to resolving #6 with a skeleton set of unit tests, but certainly needs a lot more love.

I've mostly outlined what I think is probably a good set of minimal tests for WP_JSON_Server at least. I'll be sure to also jump into CTP, Media, Pages, Posts, ResponseHandler, and Taxonomies later here.

Some notes:

• The Travis CI configuration uses my personal mirror of the develop repo (since there still isn't an official one), but really just because it's more work to deal with the logic of checking out SVN trunk versus tags for specific versions. This shouldn't matter though since this is a temporary setup that would be removed when merged to core.
• I've left a bunch of notes in the inline comments in numerous locations and todos. Since it's mostly stubbed, they're probably better off there for when someone (not just myself) gets around to writing these tests.
• The instructions for running the unit tests locally are simple: checkout develop.svn (or use my git mirror as well), configure the core unit tests as usual (wp-tests-config.php in root), install WP-API into src/wp-content/plugins, and run phpunit from the plugin directory. See tierra/wordpress-plugin-tests for more details if you like.

[tierra]

Sorry, this should have reference ticket #6, not #3 like I originally did.

[rmccue]

I'd rather reduce the number of tests by just testing against 3.8 or master, but ensure we do it with all versions of PHP.

[tierra]

Just to be clear, you're agreeing with it's current 4 test environments total then?

• PHP 5.2, WP 3.8
• PHP 5.3, WP trunk
• PHP 5.4, WP 3.8
• PHP 5.5, WP trunk

[rmccue]

I mean, let's pick either 3.8 or master and only test against that. So then we end up with, say,

• PHP 5.2, WP trunk
• PHP 5.3, WP trunk
• PHP 5.4, WP trunk
• PHP 5.5, WP trunk
• HHVM, WP trunk

(HHVM we can worry about later though, since I don't think WP passes there yet)

[tierra]

Well, at the moment, since we still need at least 4, there's certainly no harm in leaving 3.8 in there for now, and attempting to stay compatible, but I'll leave that up to you.

[rmccue]

Thanks a bunch! The main issue for me isn't writing the tests so much as it is getting the test framework in place, so this is awesome. :)

The process of running these locally is a little bit too fiddly, we should work on a Bash script that can do all of it automatically. (Which could also be used back upstream in your repo.)

[tierra]

I'm not sure what you mean by "fiddly", but it seems to me that tossing in an extra shell script step would only complicate it even more. You'd still have to manually create and configure your test DB (which is certainly still required while some of the tests need to create test accounts, posts, etc), which is why it all still ties directly into the core unit test framework.

For anyone who actually already has a checkout of WordPress with their unit tests already configured (the same way we would ask someone to configure WP if they were working on a core feature), and they already have this repo installed given your existing instructions, this is actually ridiculously easy as there's only one step:

1. Run phpunit

Not sure how it gets easier than that. :)

If you would like a shell script in the mean time though, I already have pretty much everything you need in a bash script sitting in .travis.yml under before_script. I did also leave in an alternative option to checkout WP elsewhere and define the location with a WP_DEVELOP_DIR environment var too, so it should be flexible enough to setup your environment in in way you'd like to.

[tierra]

On a more personal note btw, I would like to advocate one single location to configure a unit test DB (opting for core of course), rather than doing this individually for every plugin I write and run unit tests for. So the design does reflect my personal bias just a bit. But I would assume others would agree with that.

It would normally be up to a plugin to opt not to use the core unit testing framework (i.e. forget about the factories, DB transactions, etc), but for a core feature plugin, this wouldn't be an option, so at the least, the core unit test framework files would need to be maintained somewhere, and I also just assume they stay in their (already required) WP checkout anyway where they can still also be managed by version control (WP-CLI doesn't seem to agree with me on that though, or maybe that was just never considered).

[tierra]

I did actually mean to update this to use: $this->assertInstanceOf(...);

... but that can be updated later.