GithubHelp home page GithubHelp logo

sebastianbergmann / phpunit-documentation Goto Github PK

View Code? Open in Web Editor NEW
189.0 25.0 137.0 83.3 MB

Documentation for PHPUnit.

Home Page: https://phpunit.de/documentation.html

CSS 0.10% Perl 0.06% HTML 89.18% XSLT 9.50% Makefile 0.01% Ruby 0.01% Python 0.01% Shell 0.05% JavaScript 0.81% NewLisp 0.01% SystemVerilog 0.01% Java 0.23% PHP 0.01% Batchfile 0.01% Perl 6 0.01%

phpunit-documentation's Introduction

Building the Documentation

Requirements

  • Apache Ant
  • PHP 5 (with DOM, PCRE, SPL, and Tokenizer extensions enabled)
  • Ruby
  • xmllint
  • xsltproc

Building the Documentation

To build the complete documentation use:

cd build
ant

To build only one version of the documentation use:

cd build
ant build-LANG-VERSION

for example

cd build
ant build-en-4.3

Output

The generated files will be in build/output/VERSION/LANG.

phpunit-documentation's People

Contributors

astorije avatar baghayi avatar chriskonnertz avatar dmalouf avatar edorian avatar elazar avatar ericpoe avatar gbprod avatar giorgiosironi avatar gleidson2012 avatar henriquemoody avatar hnesk avatar jakoch avatar jean85 avatar jon5000 avatar m-takagi avatar phil-davis avatar poum avatar rafaelbdb avatar sebastianbergmann avatar squazic avatar stopfstedt avatar sun avatar suzuki avatar svenrtbg avatar timmartin avatar verber avatar whatthejeff avatar wynnchen avatar zonuexe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

phpunit-documentation's Issues

Wrong example call on Behaviour-Driven Development chapter (version 3.6)

Hello,

A. I've noticed a minor error on example about Story extension for Bowling example.

In chapter 13 on output result we may see

phpunit --printer PHPUnit_Extensions_Story_ResultPrinter_Text BowlingGameSpec
PHPUnit 3.6.0 by Sebastian Bergmann.

As --printer option does not exists, it should be replaced by --testdox

BTW, you should also add a note that users may use a --bootstrap to use Story extension Autoload

phpunit 
    --bootstrap \php-5.2.17\PEAR\PHPUnit\Extensions\Story\Autoload.php 
    --testdox BowlingGameSpec \path_to\BowlingGameSpec.php 

B. As I've tried your example, I noticed that without implements of Bowling class we get fatal error due to roll method usage in scenario

Why not to add a default template for bowling class like this one :

<?php
class BowlingGame
{
    public function __call($method, $args)
    {
    }
}
?>

Results gave (as expected or almost (see phpunit/phpunit-story#3) because none implements)

PHPUnit 3.5.15 by Sebastian Bergmann.

BowlingGameSpec
 [ ] Score for gutter game is 0
 [ ] Score for all ones is 20
 [ ] Score for one spare and 3 is 16
 [ ] Score for one strike and 3 and 4 is 24
 [ ] Score for perfect game is 300

Regards
Laurent Laville

Missing annotations

The phpunit documentation website is missing links to the following annotations on the left navigation

@codeCoverageIgnore, @codeCoverageIgnoreStart and @codeCoverageIgnoreEnd

Document --strict mode

From looking over the docs I didn't find a nice list explaining what --strict mode implies.

Writing a small section shouldn't be an issue though.

PDF Version of PHPUnit Book Missing Commands from All Example Listings

If you look at all command line examples in the PDF version of the PHPUnit Documentation you would be confused to see that the actual phpunit command is missing from the example (Furthermore, each example is printed twice.)

For a beginner learning from the PDF version, they will not notice that the command is missing and could read the whole documentation before they notice the error.

Compare PDF version of "Example 4.3. Exploiting the dependencies between tests" (at Pg 8 http://www.phpunit.de/manual/3.6/en/phpunit-book.pdf ) with the same example "Example 4.3. Exploiting the dependencies between tests" on the web at http://www.phpunit.de/manual/3.6/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.examples.DependencyFailureTest.php

Note: the PDF example is missing the crucial first line:

phpunit --verbose DependencyFailureTest

PDF version of "Example 4.3. Exploiting the dependencies between tests" (at Pg 8 http://www.phpunit.de/manual/3.6/en/phpunit-book.pdf ):

PHPUnit 3.6.0 by Sebastian Bergmann.
FS
Time: 0 seconds, Memory: 4.00Mb
There was 1 failure:
1) DependencyFailureTest::testOne
Failed asserting that  is true.
/home/sb/DependencyFailureTest.php:6
There was 1 skipped test:
1) DependencyFailureTest::testTwo
This test depends on "DependencyFailureTest::testOne" to pass.
FAILURES!
Tests: 1, Assertions: 1, Failures: 1, Skipped: 1.phpunit --verbose DependencyFailureTest
PHPUnit 3.6.0 by Sebastian Bergmann.
FS
Time: 0 seconds, Memory: 4.00Mb
There was 1 failure:
1) DependencyFailureTest::testOne
Failed asserting that  is true.
/home/sb/DependencyFailureTest.php:6
There was 1 skipped test:
1) DependencyFailureTest::testTwo
This test depends on "DependencyFailureTest::testOne" to pass.
FAILURES!
Tests: 1, Assertions: 1, Failures: 1, Skipped: 1.

Same example "Example 4.3. Exploiting the dependencies between tests" on the web:

phpunit --verbose DependencyFailureTest
PHPUnit 3.6.0 by Sebastian Bergmann.

FS

Time: 0 seconds, Memory: 4.00Mb

There was 1 failure:

1) DependencyFailureTest::testOne
Failed asserting that  is true.

/home/sb/DependencyFailureTest.php:6

There was 1 skipped test:

1) DependencyFailureTest::testTwo
This test depends on "DependencyFailureTest::testOne" to pass.

FAILURES!
Tests: 1, Assertions: 1, Failures: 1, Skipped: 1.

Brazilian Portuguese (pt-br) Translation for PHPUnit 3.7

Hi!

I just made a translation of PHPUnit3.7 documentation, but I could not figure out how to send it to the community (I'm totally new to GitHub).

How can I contribute with this translation? It's still in .odt format.

Thank you!

Include full examples to running test for all installation types (phar, composer, pear)

See sebastianbergmann/phpunit#936

I don't think many folks have problems downloading the library, but you can put the following into the PHAR section of the installation page (http://phpunit.de/manual/3.8/en/installation.html):

Installation:

Use your browser or a command line tool to download the PHP archive (PHAR).

Example using wget

wget http://pear.phpunit.de/get/phpunit.phar

Example using curl

curl -O http://pear.phpunit.de/get/phpunit.phar

Example using a browser

Navigate to http://pear.phpunit.de/get/phpunit.phar in the browser of your choice.


Next, you should clarify the conventions at the top of the "Writing Tests for PHP Unit" page (http://phpunit.de/manual/3.8/en/writing-tests-for-phpunit.html), specifically number 3 should be more clear about the naming convention and it should provide an example of the docblock syntax. Consider the following:

The tests are public methods that are named test* (i.e. the function names in your class must begin with "test", e.g. "function test1" or "function test_log")

Alternatively, you can use the @test annotation in a method's docblock to mark it as a test method. For example:

/**
 * This is my docblock that uses the test annotation.
 * @test 
 */
function test_something() {
    // ... test goes here
}

-- You should clarify that the class name is not important. It normally matches the filename, but this is not required.

-- I think you also need to clarify if and when a test function accepts arguments. It would be appropriate to say something like "A test function may also accept arguments supplied by a function named "provider". See example 4.4."

However, you should probably clean up 4.4 -- it's not clear that the function name must be "provider" and it's not clear why it returns an array with 4 elements, but the function only accepts 3 arguments. Is that intentional? Or am I missing something? Is it getting the function name from the "dataProvider" docblock attribute? You can see how little things like that can be misleading. Every time you have some variation or behavior like that, you need to have at least 2 examples that demonstrate the behavior and a variant, otherwise, people fall off the wagon.


Next you need to provide full examples showing how to execute tests, including variations for executing them using the library installed via composer, via pear, or as a .phar. The following bit should be on the http://phpunit.de/manual/3.8/en/writing-tests-for-phpunit.html page. I would recommend you create a new section called "Running the Tests". Consider the following.

Running the Tests

To demonstrate how to run PHP Unit tests, let's consider a simple test that asserts that 1 + 1 = 2. Copy and paste the following into a file named "MyFirstTest.php":

<?php
class MyFirstTest extends PHPUnit_Framework_TestCase
{
    public function testFirst()
    {
        $this->assertEquals(1 + 1, 2);
    }
}
?>

Next we will demonstrate how to run these tests. In all the variations

Running the Test via PHAR

Make sure you've downloaded the PHAR into the same directory as your test class, so that your directory contents look something like this:

  • MyFirstTest.php
  • phpunit.phar

From that directory, run the following command:

php phpunit.phar MyFirstTest

Note that the name of the test (MyFirstTest) is the name of the file, minus the ".php" extension.

Running the Test via Composer:

If you have installed PHP Unit via Composer, you can run your tests using the "phpunit" command:

vendor/bin/phpunit MyFirstTest

Running the Test via PEAR:

This is actually the install method that's being assumed in most of the documentation.

phpunit MyFirstTest

Test Output

No matter which method you use to execute your test, you should see something like the following upon successful execution:

$ php phpunit.phar MyFirstTest.php 
PHPUnit 3.7.21 by Sebastian Bergmann.

.

Time: 0 seconds, Memory: 2.50Mb

OK (1 test, 1 assertion)

Modified Test

Typically, your test classes will contain multiple testing functions. Let's augment our example of a test that succeeds (1 + 1 = 2) with a test that fails (2 + 2 = 5). Edit MyFirstTest.php so it looks like the following.

<?php
class MyFirstTest extends PHPUnit_Framework_TestCase
{
    public function testFirst()
    {
        $this->assertEquals(1 + 1, 2);
    }
    public function testSecond()
    {
        $this->assertEquals(2 + 2, 5);
    }
}
?>

Now when you run this test, your output should reflect some success and some failures. Execute the tests using the same command you used above. But now the output should look something like the following:

PHPUnit 3.7.21 by Sebastian Bergmann.

.F

Time: 0 seconds, Memory: 2.75Mb

There was 1 failure:

1) MyFirstTest::testSecond
Failed asserting that 5 matches expected 4.

/path/to/MyFirstTest.php:10

FAILURES!
Tests: 2, Assertions: 2, Failures: 1.

Sorry if this seems trivial and pedantic, but your docs are missing this section.

Add "Getting Started" chapter

The documentation should begin with a "Getting Started" chapter that covers the following:

  • Writing basic unit tests (using a useful example instead of array() and count())
  • Download the PHAR (mention alternative installation methods and link to them)
  • Run the tests using the PHAR

typo in listing chapter 8

Page 83 & 84, in listing under Tip: Use your own Abstract Database TestCase,

final public fucntion getConnection()

typo appearing twice ....

Documentation omits support for mocking static methods

From sebastianbergmann/phpunit#741:

Following the documentation at http://www.phpunit.de/manual/3.7/en/test-doubles.html, it states that PHPUnit will ignore mocking static methods, as well as private methods. It seems that this is no longer the case (as of 3.5), and Sebastian has written examples of how to mock statics and privates that would be perfect for the documentation: http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html

Ambiguous --filter description

Does the --filter parameter limit names of functions? Or the names of test classes? The explanation of the --filter parameter is unclear on http://phpunit.de/manual/3.7/en/textui.html Does the function name need to include "test" or can that part of the name be omitted?

An example of a regex for a filter would be helpful: do I need to include delimiters? Does the pattern need to be quoted?

Also example on http://phpunit.de/manual/3.7/en/organizing-tests.html does not clarify... there seems to be no relationship between the broad example test run:

phpunit Tests/FreezerTest

And the more "fine-grain" controlled example:

phpunit --filter testFreezingAnObjectWorks Tests

Are the same test classes even involved here?

Consider using the same class in both examples (assuming this is correct syntax):

phpunit --filter testSingleFunction Tests/FreezerTest

How to recompile the docs ?

Would it be possible to have some directions on how to recompile the docs ?

I'm caring because I'm thinking about packaging it for Debian, and would rather do it from the source in git, than from wgotten HTML pages

Thanks in advance.

showUncoveredFiles option missing in 3.7 English documentation

It is there in the 3.6 manual:

http://www.phpunit.de/manual/3.6/en/appendixes.configuration.html#appendixes.configuration.logging

and missing in 3.7:

http://www.phpunit.de/manual/3.7/en/appendixes.configuration.html#appendixes.configuration.logging

it appears in the French 3.7 version, however:

http://www.phpunit.de/manual/3.7/fr/appendixes.configuration.html#appendixes.configuration.logging

It would be nice id this could be made a bit more consistent. Also, after reading both versions, I'm not entirely sure it this setting only applies to the text log. It sounds a bit like it, but it would be good if this could be explicitly stated (I'm asking because I woudl like to have this behaviour in the XML loggers, if that's at all possible)

$this-> call to self:: call

In the documentation, $this call is used everywhere, e.g. $this->assertArrayHasKey, $this->assertEquals, etc.

However, those functions are all static functions.
Though PHP does support that, would it be great to use the 'right way' to call a static function?

I checked some other Unit, they are using Assert.assert.

Missing Upgrading Instructions

I have php 5.4.10 and after following the installation instructions, the latest version I get is 3.7.22. The Upgrading Instructions on the site now are about as useless as a one legged ass kicking competition

Document setMethods(null)

The PHPUnit call "setMethods()" can be called with "null" as an argument if you don't want to mock any methods on an object. This is useful if the only purpose you're mocking an object is so you can avoid calling its constructor, and you need to call a real method on that object to test it. setMethods(null) isn't covered in the PHPUnit documentation, however.

I recommend that two lines on "http://www.phpunit.de/manual/3.6/en/test-doubles.html" be modified:

  • When an array is provided as the second (optional) parameter, only the methods whose names are in the array are replaced with a configurable test double. The behavior of the other methods is not changed. Providing NULL as the parameter means that no methods will be replaced.
  • setMethods(array $methods) can be called on the Mock Builder object to specify the methods that are to be replaced with a configurable test double. The behavior of the other methods is not changed. If you call setMethods(NULL), then no methods will be replaced.

Undocumented core options from the XML configurations file

As mentioned in sebastianbergmann/phpunit#133, some core options for the XML configuration file are missing from the docs:

3.5:

Add:

  • ansi
  • forceCoversAnnotation
  • mapTestClassNameToCoveredClassName
  • stopOnError
  • stopOnIncomplete
  • stopOnSkipped
  • testSuiteLoaderFile

3.6:

Add:

  • ansi
  • forceCoversAnnotation
  • mapTestClassNameToCoveredClassName
  • printerClass
  • printerFile
  • stopOnError
  • stopOnIncomplete
  • stopOnSkipped
  • testSuiteLoaderFile

Delete:

Instructions on to get rid warnings when building JA docs

I don't know how to get rid of those warnings. I assume I'd need to install some fonts to properly build the JA docs.

Can someone, maybe @m-takagi ?, add a little note to the readme what to do to avoid those warnigs?

WARNING: Glyph "テ" (0x30c6, tekatakana) not available in font "Times-Bold"

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.