Skip to content

Latest commit

 

History

History
102 lines (79 loc) · 5.67 KB

testing.md

File metadata and controls

102 lines (79 loc) · 5.67 KB
Raw

Automated Testing For Caldera Forms

Starting in 2018, Caldera Forms began to adopt test-driven development (TDD). I wrote a post about adopting TDD based on this We are as test-driven as we can and employ several layers of testing -

  • Unit tests
    • Isolated tests run with Jest (JavaScript) or phpunit (PHP).
  • Integration tests
    • We use the WordPress "unit" test suite for these tests. This repo provides a Docker environment that they run it.
  • Acceptance tests
    • We use Cypress and Ghost Inspector.

Installation

All of these tools are installed and run with Composer and npm. See local dev documentation

Test-First

NOTE: You should read the article on pull request workflow before developing for Caldera Forms.

When working on a bug or feature, you should follow red/green TDD flow:

  • Write tests that would pass if the bug was fixed or the feature was completed.
  • Push to Github and open a pull request
    • Automated tests should fail.
    • Travis and Github will indicate PR can not be merged with a RED light.
  • Write code that makes the tests pass.
  • Push to Github
    • Automated tests should pass
    • Travis and Github will indicate PR can not be merged with a GREEN light.

Recommended Reading

Locations For Tests

  • PHP tests go in /tests and are run using phpunit
    • Unit tests -- isolated tests that do NOT require WordPress -- go in tests/Unit.
      • These tests are run with composer test:unit.
      • You may NOT use any functions from WordPress core, without mocking.
    • Integration tests, which require WordPress, are in /tests and /tests/Integration
      • Tests in tests/Integration are newer tests, and use a PSR-4 autoloader, etc.
      • Tests in the main /tests are older. That used to be all of our tests.
        • For the most part, only add integration tests in tests/Integration
    • The trait calderawp\calderaforms\Util\Traits should have all of the factories used for integration and unit tests.
      • This is an aspirational goal, and partially true.
  • JavaScript UNIT tests go in clients/tests
    • Unit tests go in clients/tests/unit and are run using Jest
    • Unit tests must have the word test in file name. For example, formConfig.test.js
  • End to end tests go in cypress/integration amd are written using Cypress

JavaScript Testing

We write our tests using Jest.

Tools

  • Jest - Unit tests, assertions and test runner.
  • react-test-renderer Basic React rendering for unit tests. Run by Jest.
  • Enzyme - More advanced React rendendering for isolated DOM testing and other integration tests. Run by Jest.

Recommended Reading

I wrote a series of posts on testing React in context of Gutenberg for Torque:

Other recommended reading:

Relevant CLI Commands

  • npm test - Run JavaScript test watcher
  • npm run test:once - Run JavaScript unit tests once
  • composer test:setup - Adds test forms and puts them on pages.

PHP Testing

We use phpunit to run unit tests and acceptance tests.

Tools

Relevant CLI Commands

  • composer test:php - Run PHP tests -- isolated unit tests and the WordPress integration tests.
  • composer wp:tests - Runs the PHP integration tests using phpunit inside Docker-based environment.
  • composer test:unit - Run php unit tests.

Recommended Reading

Acceptance Testing

We primarily use Ghost Inspector to write and run acceptance tests against a live WordPress site. We have not yet automated this part. For Caldera Forms 1.8, we added acceptance tests with Cypress, because they are written in code and easier to automate. Also, we can run them locally.

Relevant CLI Commands

  • npm run test:e2e - Start Cypress e2e test runner.

Tools Used

Recommenced Reading