.. ==================================================
.. FOR YOUR INFORMATION
.. --------------------------------------------------
.. -*- coding: utf-8 -*- with BOM.
.. include:: ../../Includes.txt
.. _FunctionalTestingWorkflow:
==================================
The Workflow of Functional Testing
==================================
.. contents::
:local:
:backlinks: none
The Basic Workflow
==================
I first manually create the output I want in the usual way. This gives me
a working DB and output that I can control visually. Now this needs to be
packed into a test that I can run with different versions of PHP and TYPO3.
A good solution to run this test triggered by each `GIT` commit is the
combination of `Github` and `Travis`.
I export a minimalized version of table data and `TypoScript` setup. This is
bundeled with the functional test class. Export means, I either create the
`XML` files by hand or I actually export a selection of the data in the
database as `XML`.
The TYPO3 XML DB Fixture Format
===============================
The examples will show how the `XML` should be structured that the `TYPO3`
functional testing expects. It usually differs a little from the `XML`
that is exported by the tools and needs to be adjusted accordingly.
The enclosing tag is ``dataset``. The children have the names of the
tables. That is one tag per dataset, not per table. The tags of the
sublevel name the fields.
.. code-block:: xml
1
0
[ ... more fields here ... ]
1
0
[ ... more fields here ... ]
1
0
[ ... more fields here ... ]
[ ... more datasets here ... ]
Size of the Fixtures
====================
I try to keep the fixtures as small is reasonable. In general I reduce the
exports to the fields of interest and trust that the DB is set up well enough,
to set the other fields to reasonable default values. Giving up the full
control over the fixture is a price I pay, to gain more speed in writing tests,
better readability and lower costs of maintenance.
If bugs are observed, it becomes necessary to write tests with a more
detailed control of the fixture.
Exporting XML Datasets to Fixtures
==================================
Tools like `MySQL Workbench` or `Sequel Pro` offer options
to export selected data to XML. This can be used to create `XML` files that
serve as fixtures.
----------
Sequal Pro
----------
First I query the data I want to export by an `SQL query`. Then I click
``Menue > File > Export``. In the popup form I select **XML**,
**Query Results** and **Plain Schema** and the path to save the file to.
Trimming the Output and Including Multiple Templates
====================================================
To focus on the matter of interest, it can get usefull to trim all surrounding
tags, `HTML`, `HEAD`, `BODY`. This is easily done by the `TypoScript`
setting ``config.disableAllHeaderCode``.
Here I include an additional `TypoScript` file `Trim.ts`, that contains just
one line, and test, that the output is actually **equal** to the expectation.
By splitting files this way, I can compose different tests. It shows,
how multiple templates are included. (Just as example. Keep it simple
in practice!)
--------
The Test
--------
.. code-block:: php
importDataSet(
'typo3/sysext/core/Tests/Functional/Fixtures/pages.xml');
$this->setUpFrontendRootPage(1, [
'EXT:ehfaq/Tests/Functional/Fixtures/Hello.ts',
'EXT:ehfaq/Tests/Functional/Fixtures/Trim.ts',
]);
}
/**
* @test
*/
public function trimmedPageOutput()
{
$response = $this->getFrontendResponse(1);
$this->assertEquals("
Hello world!
",
$response->getContent());
}
}
?>
------------
The Fixtures
------------
See :ref:`fixtures`.
The file `Fixtures/Trim.ts` is additionally included.
.. code-block:: none
config.disableAllHeaderCode = 1