Jump to content

Using Nette Tester with ProcessWire


tpr
 Share

Recommended Posts

Update 2018-07-09: ProcessNetteTester module is available in the Modules Directory and on GitHub.

processnettetester.thumb.png.ca7e5a36e142095fb2db7cf08a8c9a86.png

This is a short tutorial on how to use Nette Tester with ProcessWire.

As you will see it's very easy to setup and use and it's perfect for testing your code's functionality. With bootstrapping ProcessWire it's also possible to check the rendered markup of pages using the API, checking page properties, etc. It's also a great tool for module developers for writing better code. 

While there will be nothing extraordinary here that you couldn't find in Tester's docs this can serve as a good starting point.

Prerequisites: PHP 5.6+

01 Download Tester

Go to https://github.com/nette/tester/releases and download the latest release (currently 2.0.2). Download from the link reading "Source code (zip)". You can use composer also if you wish.

02 Extract Tester files

Create a new directory in your site root called "tester". Extract the zip downloaded here, so it should look like this:

/site
/tester/src
/tester/tools
/tester/appveyor.yml
/tester/composer.json
/tester/contributing.md
/tester/license.md
/tester/readme.md
/wire
...

03 Create directory for test files

Add a new directory in "/tester" called "tests". Tester recognizes "*.Test.php" and "*.phpt" files in the tests directory, recursively. 

04 Create your first test

In the "tests" directory create a new "MyTest.php" file.

The first test is a very simple one that bootstraps ProcessWire and checks if the Home page name is "Home". This is not the smartest test but will show you the basics.

Add this to "/tester/tests/MyTest.php":

<?php namespace ProcessWire;

use \Tester\Assert;
use \Tester\DomQuery;
use \Tester\TestCase;
use \Tester\Environment;

require __DIR__ . '/../src/bootstrap.php'; // load Tester
require __DIR__ . '/../../index.php'; // bootstrap ProcessWire

Environment::setup();

class MyTest extends TestCase
{
    // first test (step 04)
    public function testHomeTitle()
    {
        $expected = 'Home'; // we expect the page title to be "Home"
        $actual = wire('pages')->get(1)->title; // check what's the actual title
        Assert::equal($expected, $actual); // check whether they are equal
    }

    // second test will go here (step 06)
    // third test will go here (step 07)
}

// run testing methods
(new MyTest())->run();

I've added comment placeholders for the second and third tests that we will insert later.

05 Run Tester

Tester can be run either from the command line or from the browser. The command line output is more verbose and colored while in the browser it's plain text only (see later).

Running from the command line

Navigate to the "/tester" directory in your console and execute this:

php src/tester.php -C tests

This will start "/tester/src/tester.php" and runs test files from the "/tester/tests" directory. The "-C" switch tells Tester to use the system-wide php ini file, that is required here because when bootstrapping ProcessWire you may run into errors (no php.ini file is used by default). You may load another ini file with the "-c <path>" (check the docs).

If the title of your Home page is "Home" you should see this:

tester-ok.png.7af030edf8d090a2d50c38ce87fa5d5a.png

If it's for example "Cats and Dogs", you should see this:

tester-failure.png.0e1a44f116602b4373221ddfacd4850d.png

Running from the browser

First we need to create a new PHP file in ProcessWire's root, let's call it "testrunner.php". This is because ProcessWire doesn't allow to run PHP files from its "site" directory.

The following code runs two test classes and produces a legible output. IRL you should probably iterate through directories to get test files (eg. with glob()), and of course it's better not allow tests go out to production.

<?php
ini_set('html_errors', false);
header('Content-type: text/plain');

echo 'Starting tests.' . PHP_EOL;
echo '--------------------------' . PHP_EOL;

$file = __DIR__ . '/PATH_TO/FirstTest.php';
echo basename($file) . ' ';
require $file;
echo '[OK]' . PHP_EOL;

$file = __DIR__ . '/PATH_TO/SecondTest.php';
echo basename($file) . ' ';
require $file;
echo '[OK]' . PHP_EOL;

echo '--------------------------' . PHP_EOL;
echo 'Tests finished.';

exit;

Navigate to "DOMAIN/testrunner.php" in your browser to execute the file. If every test succeeds you should get this:

tester-ok-browser.png.bd4dc2b5d69f1be26ea2b00eabdd286f.png

If there are failed tests the execution stops and you can read the error message. If there were more tests (eg. ThirdTest), those won't be displayed under the failed test.

tester-failure-browser.png.1a89ccae06b187ab56fa9482b61e9240.png

06 DOM test

This test will check if a page with "basic-page" template has a "h1" element. We will create the page on the fly with ProcessWire's API. To keep things simple we will add the new test as a new method to our MyTest class.

Add this block to the MyTest class:

public function testBasicPageHeadline()
{
    $p = new Page();
    $p->template = 'basic-page';
    $html = $p->render();
    $dom = DomQuery::fromHtml($html);

    Assert::true($dom->has('h1'));
}

This will most likely be true but of course you can check for something more specific, for example "div#main". Note that we have used the DomQuery helper here (check the "use" statement on the top of the file).

07 Custom function test

You will probably want to make sure your custom functions/methods will work as they should so let's write a test that demonstrates this.

I don't want to complicate things so I'll check if the built-in "pageName" sanitizer works as expected. Add this to the myTest class:

public function testPageNameSanitizer()
{
    $expected = 'hello-world';
    $actual = wire('sanitizer')->pageName('Hello world!', true);

    Assert::equal($expected, $actual);
}

This should also be true. Try to change the expected value if you are eager to see a failure message.
 
08 Next steps

You can add more methods to the MyTest class or create new files in the "tests" directory. Check out the range of available Assertions and other features in the docs and see how they could help you writing more fail-safe code.

Once you make a habit of writing tests you'll see how it can assist making your code more bulletproof and stable. Remember: test early, test often 🙂

If you find out something useful or cool with Tester make sure to share.

  • Like 19
  • Thanks 2
Link to comment
Share on other sites

Honestly I haven't went that far yet but the closest I found are the setUp and tearDown methods (see the docs). Of course this creates holes in the autoincrement ids but I don't think that matters much. 

Method calls order
------------------
setUp()
testOne()
tearDown()

setUp()
testTwo()
tearDown()
  • Like 1
Link to comment
Share on other sites

When using setUp and tearDown methods it's good to keep in mind that Tester runs tests in parallel threads. That is, if you except that a Page you create in the setUp method will be deleted in tearDown before the next test method begins, you may be wrong.

For example I've created and saved a new Page with the same title in setUp and deleted it in tearDown. I randomly got a ProcessWire error saying it could not generate a unique name for the page, and that was because the other tests have been started before the page could be deleted in the tearDown method.

The actual thread number can be retrieved, so appending it to the title solved the issue (or by adding a random suffix):

$p->title = 'Test ' . getenv(\Tester\Environment::THREAD);

Alternatively you can reduce the number of threads to 1 with the "-j 1" switch (runtime will increase a lot).

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

I'm working on a module that makes easier to run tests, from within the admin. It's a process module and you can add pages anywhere in the admin and set each page a tests directory. So you can add new tester pages, or specify a path to an existing tests directory, see my TemplateLatteReplace module's tests in action on the screencap. Furthermore you can narrow the list of tests within a directory with URL parameters, to include only a few tests or exclude some. This may come handy if you don't want to run all the tests within a directory.

Another handy feature is that you can re-run tests via ajax, that makes it easy to check whether your fixes are working (whether in "real" code or in test code).

processnettetester.thumb.gif.f6e93f5b9eec35e88d3958f291fef11b.gif

  • Like 9
Link to comment
Share on other sites

I'm close to release the initial version of the module, only a few issues are left behind.

I rewrite the UI so it uses ajax all the time. It was an overkill to start all test on page load, plus it was done in one PHP thread which involved a few issues (timeout, included files were inherited by next tests, etc). With ajax it's not only user-friendlier but more reliable too, and it's possible to catch PHP errors too (beforehands the syntax error was outputted on the whole page).

I also managed to format the Assert error message so now it's much easier to grasp the message.

I really like how it looks and works now. Even so it seems simple the JS part was tricky sometimes 🙂

processnettetester-20180705.thumb.gif.682e100030265b137bca591426405d6a.gif

  • Like 5
Link to comment
Share on other sites

Hello there, it is good to hear that someone cares about code testing in PW community. Some time ago I've created a tool which helps you to run your tests against multiple version of PW quite easily. You can check it out there: https://github.com/uiii/tense. It is compatible with any testing framework. I would be really glad if I'm not the only one using it 🙂

  • Like 1
Link to comment
Share on other sites

 

5 hours ago, Richard Jedlička said:

... I've created a tool which helps you to run your tests against multiple version of PW quite easily. You can check it out there: https://github.com/uiii/tense. ...

But the truth is my tool is more suitable for module or site profile development rather than for site testing, where you would test the specific PW instance.

  • Like 1
Link to comment
Share on other sites

6 hours ago, Richard Jedlička said:

Hello there, it is good to hear that someone cares about code testing in PW community.

Well I'm a starter only but it's fun, and knowing you can any time run tests to ensure everything is OK is invaluable.

  • Like 6
Link to comment
Share on other sites

  • 2 months later...

Hello,

I am discovering PHP tests and this great module (thanks !).

Just to mention in case it helps others. The first example kept failing on my website until I understood it was due to the multilanguage setup. Eventually, test 01 became :

	    public function testHomeTitle()
    {
      $expected = 'Home'; // we expect the page title to be "Home"
      $actual = wire('pages')->get(1)->title->getLanguageValue("default"); // check what's the actual title
      Assert::equal($expected, $actual); // check whether they are equal
    }

and passed 🙂 

This may seem perfectly obvious to most of you, but it might help a few ?

By the way, I wish I could use my usual debugging tools to debug my tests (sounds quite funny to say 🙂 ) and write something like 

	bd($actual);
	

Here I had to fiddle until I found out about my multiLanguage thing... Would you have any tips on that ?

 

Link to comment
Share on other sites

3 minutes ago, celfred said:

By the way, I wish I could use my usual debugging tools to debug my tests (sounds quite funny to say 🙂 ) and write something like 


	bd($actual);
	

Here I had to fiddle until I found out about my multiLanguage thing... Would you have any tips on that ?

It might be a module load order issue. Please try grabbing the latest dev version of PW and the latest Tracy and see if that helps. Tracy is now the first module loaded so that should hopefully solve things for you.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

On 9/23/2018 at 5:41 PM, adrian said:

It might be a module load order issue. Please try grabbing the latest dev version of PW and the latest Tracy and see if that helps. Tracy is now the first module loaded so that should hopefully solve things for you.

Thanks a lot for your quick help. But I'm not that good and I am running PW 3.0.62 both on local and production. I won't update right now because I'm not able to easily manage different version on local and remote... So I'll manage little by little and do the update later 🙂 But thanks !

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By MarkE
      This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API.
      The API consists of a number of predefined functions, some of which include...
      render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for creating a new measurement object from the sum or difference between two other objects. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m.
      A simple length field using Fieldtype Measurement and Inputfield Measurement.
      Combination units (e.g. feet and inches) are also supported.
      Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly.
      See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.
    • By tcnet
      File Manager for ProcessWire is a module to manager files and folders from the CMS backend. It supports creating, deleting, renaming, packing, unpacking, uploading, downloading and editing of files and folders. The integrated code editor ACE supports highlighting of all common programming languages.
      https://github.com/techcnet/ProcessFileManager

      Warning
      This module is probably the most powerful module. You might destroy your processwire installation if you don't exactly know what you doing. Be careful and use it at your own risk!
      ACE code editor
      This module uses ACE code editor available from: https://github.com/ajaxorg/ace

      Dragscroll
      This module uses the JavaScript dragscroll available from: http://github.com/asvd/dragscroll. Dragscroll adds the ability to drag the table horizontally with the mouse pointer.
      PHP File Manager
      This module uses a modified version of PHP File Manager available from: https://github.com/alexantr/filemanager
       
    • By tcnet
      This module implements the website live chat service from tawk.to. Actually the module doesn't have to do much. It just need to inserted a few lines of JavaScript just before the closing body tag </body> on each side. However, the module offers additional options to display the widget only on certain pages.
      Create an account
      Visit https://www.tawk.to and create an account. It's free! At some point you will reach a page where you can copy the required JavaScript-code.

      Open the module settings and paste the JavaScript-code into the field as shown below. Click "Submit" and that's all.

      Open the module settings
      The settings for this module are located int the menu Modules=>Configure=>LiveChatTawkTo.

       
    • By tcnet
      Session Viewer is a module for ProcessWire to list session files and display session data. This module is helpful to display the session data of a specific session or to kick out a logged in user by simply delete his session file. After installation the module is available in the Setup menu.

      The following conditions must be met for the module to work properly:
      Session files
      Session data must be stored in session files, which is the default way in ProcessWire. Sessions stored in the database are not supported by this module. The path to the directory where the session files are stored must be declared in the ProcessWire configuration which is by default: site/assets/sessions.
      Serialize handler
      In order to transform session data easier back to a PHP array, the session data is stored serialized. PHP offers a way to declare a custom serialize handler. This module supports only the default serialize handlers: php, php_binary and php_serialize. WDDX was dropped in PHP 7.4.0 and is therefore not supported by this module as well as any other custom serialize handler. Which serialize handler is actually used you can find out in the module configuration which is available under Modules=>Configure=>SessionViewer.

      Session data
      The session data can be displayed in two different ways. PHP's default output for arrays print_r() or by default for this module nice_r() offered on github: https://github.com/uuf6429/nice_r. There is a setting in the module configuration if someone prefers print_r(). Apart from the better handling and overview of the folded session data the output of nice_r() looks indeed nicer.

      Links
      ProcessWire module directory
      github.com
    • By Robin S
      Repeater Easy Sort
      Adds a compact "easy-sort" mode to Repeater and Repeater Matrix, making those fields easier to sort when there are a large number of items.
      The module also enhances Repeater Matrix by allowing a colour to be set for each matrix type. This colour is used in the item headers and in the "add new" links, to help visually distinguish different matrix types in the inputfield.
      Screencasts
      A Repeater field

      A Repeater Matrix field with custom header colours

      Easy-sort mode
      Each Repeater/Matrix item gets an double-arrow icon in the item header. Click this icon to enter easy-sort mode.
      While in easy-sort mode:
      The items will reduce in width so that more items can be shown on the screen at once. The minimum width is configurable in the field settings. Any items that were in an open state are collapsed, but when you exit easy-sort mode the previously open items will be reopened. You can drag an item left/right/up/down to sort it within the items. The item that you clicked the icon for is shown with a black background. This makes it easier to find the item you want to move in easy-sort mode. You can click an item header to open the item. An "Exit easy-sort mode" button appears at the bottom of the inputfield. Configuration
      In the field settings for Repeater and Repeater Matrix fields you can define a minimum width in pixels for items in easy-sort mode. While in easy-sort mode the items will be sized to neatly fill the available width on any screen size but will never be narrower than the width you set here.
      In the field settings for Repeater Matrix you can define a custom header colour for each matrix type using an HTML "color" type input. The default colour for this type of input is black, so when black is selected in the input it means that no custom colour will be applied to the header.
      Exclusions
      The easy-sort mode is only possible on Repeater/Matrix fields that do not use the "item depth" option.
       
      https://github.com/Toutouwai/RepeaterEasySort
      https://processwire.com/modules/repeater-easy-sort/
×
×
  • Create New...