Answer to your initial questions:
A1) The class extends WP_UnitTestCase which is a part of wordpress automated test suite (this has a few more functions https://github.com/nb/wordpress-tests (setUp, tearDown, clean_up_global_scope, flush_cache) https://github.com/nb/wordpress-tests/blob/master/lib/testcase.php – that is built upon an extension on PHPUnit_Framework_TestCase. http://apidoc.phpunit.de/classes/PHPUnit_Framework_TestCase.html
How this class works can also be documented here: http://apidoc.phpunit.de/classes/PHPUnit_Framework_TestCase.html#introduction
Usually yes prefix the functions which you want to asset as test with the word ‘test’ There are specific functions within this class for doing things like setup() How you want to initialize anything before each test is run and the cleanup function tearDown() which is run after each test.
Q2) How are these functions called. This is managed by PHPUnit http://phpunit.de/
There is a helpful presentation linked here: http://phpunit.de/presentations.html
Q3) Ok so how are the tests run on travis
If you look in your travis.yml on line 63 in travis you see it runs a command called phpunit
http://phpunit.de/manual/3.7/en/textui.html This tells travis to run the phpunit test runner from the command line. So phpunit will read your phpunit.xml.dist and run the test files you listed in the tests folder. (You see it reading this file at line 69)
How do you know if it has ran your tests. There are two ways. First way is to count the number of tests you have. In our example we have 4 tests so you can see at line 75 it says OK (4 tests, 4 assertions) If you increment the number of tests or assertions these counters should increment.) As a test you should try this maybe just copy the first test rename it to test_test2 and see this line 75 increment to understand.
The second way is to echo out something so you can see it in the travis log. If you look at landing-pages.php line 134 you see I have an echo statement which is then shown in travis log at line: 71
You can have this echo in your tests it doesn’t necessarily need to be in your functions in your code if you wish so you might want to put an echo ‘Test 5 is running’ echo ‘Test 6 is running’ and you will see this message in the travis log next time you run the tests. So as an exercise I recommend once you tried incrementing the counters to try adding the echo in the tests and see the output in travis.
Automated Tests on Landing Pages
# Tell Travis CI we’re using PHP
# PHP version used in first build configuration.
# WordPress version used in first build configuration.
# The various matrix of wordpress versions and php versions you want to test against. You can remove some if you only want to test against a specific version
– php: “5.3”
– php: “5.4”
– php: “5.2”
You will need to change line 12:
‘active_plugins’ => array( ‘landing-pages/landing-pages.php’ ),
To point to the plugin folder and the main plugin file.
You will need to also change in: test_wordpress_plugin_tests.php
Line 24: $this->assertTrue( is_plugin_active( ‘landing-pages/landing-pages.php’ ) );
To be the same as mentioned above for another project.
Writing Unit Test Foundations
All tests run under the tests folder as described in phpunit.xml.dist
If you want to modularize the code you should copy the layout of test_wordpress_plugin_tests.php and name the files with the prefix test e.g. test_check_impressions.php
Assert basics. With assert we compare the value of a function or something to be what we expect it to be, example: $this->assertTrue( landingpages_is_active() ); Because this function returns true the test will pass because we checking for the true return result.
More complex asserts can be written like assertEquals() so if for example our impression incremental function would return back the impression count it would look something like this
$this->assertTrue( 1, inbound_impression_increment() );
We assuming the function inbound_impression_increment() would return back the incremented impression count so we assert what we expect as the first argument against the function the second argument.
Guiding Principals in TDD
Functions should be written to be callable from the unit test code. Functions should always return back an expected result to be testable. E.g. Boolean, string, number, array.
When this case is satisfied the code is testable and a test can be written.
The same approach can apply for classes etc…