Manual:PHP unit testing/Writing unit tests/cs



Obecná rada
Příručka PHPUnit poskytuje pokyny pro pochopení a vývoj testování jednotek. Zvláštní pozornost věnujte sekcím o testech psaní a organizování.



Vývoj osvědčených postupů
Vývojáři noví v testování jednotek v MediaWiki by měli jako výchozí bod použít – obsahuje užitečné komentáře, které usnadní proces učení se jak psát testy jednotek.

Dalším zdrojem jsou slidy z přednášky PHPUnit Best Practices (Doporučené postupy PHPUnit), kterou Sebastian Bergmann přednesl na OSCON 2010.

Vývojáři by se měli vyvarovat vymýšlení nových konvencí nebo vypůjčování konvencí z jiných rámců. Použití již dobře zavedených konvencí PHPUnit poslouží k tomu, aby byly testy MediaWiki užitečné a použitelné.

Jednotkové testy by se měly řídit A Set of Unit Testing Rules (Sada pravidel testování jednotek) od Michaela Featherse.



Napište testovací kód
MediaWiki nebyla napsána s cílem být testovatelná. Všude používá globální proměnné a na mnoha místech statické metody. Toto je dědictví, které musíme přijmout, ale snažte se tyto věci nezavádět do nového kódu a zkuste to v budoucnu změnit.

Dobrým zdrojem může být Guide to Testability Miška Heveryho. (Miško Hevery je [jeden z?] agilních trenérů Google.)



Testovací konvence
Název souboru musí končit. Jako výchozí bod použijte.



setUp a tearDown

 * Musí být  funkcí.
 * tearDown by měl být v opačném pořadí než setUp.
 * setUp začíná voláním svého rodiče.
 * tearDown končí voláním svého rodiče.



Rozhodovací funkce

 * Musí být  funkcí.
 * Název funkce by měl být v lowerCamelCase a začínat slovem . Např..
 * Kdykoli je to možné, odkazujte na nejdůležitější testovací metodu. Např. je testován v.



Poskytovatelé dat

 * Musí být  funkcí.
 * Název poskytovatele dat by měl být uveden v nižšímCamelCase a začínat slovem . Např..
 * Neměli byste vytvářet instanci služeb MediaWiki, protože poskytovatelé dat jsou voláni přes . Například místo  použijte , abyste se vyhnuli vytvoření.



Sdělení
Výstup testu by měl sdělit závěr. The  output format is a good way to view this story: a test suite execution is displayed as a set of statements about the test classes, along with whether or not they have passed. The statements (unless customized) are the test method names with corrected capitalization and spacing.

The  annotation can be used to customize the message that is displayed. It is not currently used in the MediaWiki codebase.

See "Other Uses for Tests" for more information.



Počet tvrzení
Pouze jedno tvrzení na test, pokud k tomu není dobrý důvod (možná bude nutné seskupit cenné testy).

Selhání
Usually tests code shouldn't do, but use the phpunit fail method:

To by se projevilo jako selhání v souhrnu testování, než aby se celá sada testů zhroutila.

Specific to MediaWiki


Testy seskupení
PHPUnit umožňuje zařadit testy do libovolných skupin. Groups of tests can be selected for execution or excluded from execution when the test suite is run (see the @group annotation, The Command-Line Test Runner and XML Configuration File documentation in the PHPUnit manual for additional details.)

To add a test (or class) to a group, use the  annotation in the docblock preceding the code. Například:

V testech jednotek MediaWiki se v současnosti používá několik funkčních skupin:


 * API - Tests that exercise the MediaWiki API.
 * Broken - Put broken tests into group Broken. Tests in this group will not be run (as is configured in ).
 * Database - Tests that require database connectivity should be put into group Database.


 * Destructive - Tests that alter or destroy data should be put into group Destructive.
 * Search - Tests that use MediaWiki's built-in search put into group Search.
 * SeleniumFramework - Tests that require SeleniumFramework to be installed should be put in group SeleniumFramework.
 * Stub - Put test stubs into group Stub. Tests in this group will not be run (as is configured in ).
 * sqlite - Tests that use SQLite should be put into group sqlite.
 * Standalone - Very slow tests that should not be run in the gate, to help keep tests fast for other gated extensions.
 * Upload - Tests that upload files should be put into group Upload.
 * Utility - Currently unused by any test. Tests in this group will be not be run (as is configured in ).

Kromě toho mohou být testy seskupeny na základě rozhodnutí vývojového týmu:


 * Fundraising
 * EditorEngagement
 * Internationalization
 * etc.

To test only a particular group, use the  flag from the command line:

composer phpunit:entrypoint -- --group Search

or if you use the Makefile in core/tests/phpunit:

make FLAGS="--group Search" target

where target can be phpunit, safe, etc.

Pokrytí
The PHPUnit documentation has a chapter about coverage. There is a coverage report for MediaWiki core generated twice a day. As the forceCoversAnnotation option should be in effect the test should be marked with @covers annotations to express which parts of the code the test actually checks (as opposed to code that is just run but whose results are never tested for with assertions).

Note that  requires fully-qualified class names (unlike  annotations such as  ).

Class
You will want to extend one of the MediaWiki test classes.

The following are some common MediaWiki test classes to extend. Bullets at a lower level extend their parent.


 * - PHPUnit's test class
 * - For unit tests of true functions that don't have any dependencies. These are customarily put in their own subfolder called
 * - Assists with testing classes that access global variables, methods, services, or a storage backend. Prevents sending actual emails. Sometimes in a subfolder called . Can safely test the SQL database if you add   to your tests.
 * - Does some language setup such as  and   and does
 * - Has some extra methods such as,  ,  , etc.
 * - For testing MediaWiki maintenance classes.

Databáze
When testing database-dependent code, you should put your test case in the Database group (see above). That tells MediaWikiTestCase to setup a  database connection for you to use in. Normally, this uses a separate temporary database, with certain limited data prefilled by, including a 'UTSysop' user and a 'UTPage' title. (The temporary database is created with, and the tables are prefixed with  .) A test case can add additional data to the database by overriding  (which by default does nothing).

Pokud chcete použít jinou DB tabulku (řekněme pro vaše rozšíření), není ve výchozím nastavení k testování. To add the table to the temporary database constructed during testing, you need to add it to, for example:

Upozorňujeme však, že z vaší skutečné databáze se zkopíruje pouze schéma tabulky, nikoli existující data v této tabulce.

You can directly test the current contents of the database with.

Zde je několik příkladů z rozšíření, na která se můžete podívat pro referenci:


 * - from
 * - from

Tests that are not in the Database group still run against a temporary cloned database (even if they ignore and instead use e.g.  directly); however, this database is only set up once for the whole test run, and not reset between test runs. Testy by se pokud možno neměly spoléhat na tento bezpečnostní prvek.



Údržbářské skripty
Test cases for should inherit from, to handle the different output channels used by maintenance scripts.

The base test case method will instantiate your   object for you, if you specify the class to construct by providing the mandatory  in your subclass:

In the unlikely event that you want to do something special to instantiate the class under test, you can override the method, but hopefully this isn't needed.

Ve výchozím nastavení bude výstup skriptu údržby potlačen a ignorován. Pokud chcete otestovat výstup (to je dobrý nápad), použijte kód jako: