sitecrafting / conifer

:evergreen_tree: A powerful WordPress library plugin for OO development
https://www.coniferplug.in
MIT License
18 stars 2 forks source link

Support the WordPress "unit" test framework #119

Closed acobster closed 3 years ago

acobster commented 4 years ago

Expected behavior

As a contributor to Conifer, I want to be able to use WordPress's test factories to create data I can consume in unit tests:

    function testPostCustomField(){
        $post_id = $this->factory->post->create();
        update_post_meta($post_id, 'gameshow', 'numberwang');
        $post = new TimberPost($post_id);
        $this->assertEquals('numberwang', $post->gameshow);
    }

To support this we'll need something like Timber's install-wp-tests.sh to run inside Lando's test environment. Ideally we could keep the test database completely separate from the dev database that https://conifer.lndo.site connects to.

Actual behavior

We're relying on a combination of WP_Mock, WP YAML Fixtures, and Cypress to do end-to-end testing. E2E gives very high confidence but is also a pain to set up because it requires frontend (theme-level) code and a (headless) browser. It's also more brittle for that reason. WP_Mock is easier and allows for "true" unit tests by decoupling the database, but is also a bit painstaking since you have to determine which values to mock through trial and error. It also does not induce high confidence because it's very easy to get mocked values wrong.

Steps to reproduce behavior

lando unit

What version of WordPress/PHP/Timber/Conifer are you using?

All the versions.

How did you install Conifer? (for example, via git clone, GitHub zip download, Composer/Packagist?)

N/A

szepeviktor commented 3 years ago

Please consider using https://github.com/Automattic/wordbless

WorDBless allows you to use WordPress core functions in your PHPUnit tests without having to set up a database and the whole WordPress environment

acobster commented 3 years ago

WordBless looks pretty nice, but it doesn't do as much as wp_mock does and we're already using that. What we really need in conjunction to the unit test coverage we have now is integration tests, and mocks tend to defeat the purpose of the whole "integration" part. :slightly_smiling_face: My approach in this case is going to be: