Unit Tests

[alganet]

Unit Tests

[alganet]

I'll write up some possible fixes while writing unit tests, just reminders for ourselves in the future. My goal is to fix them after the tests for the current code.

• We should check if the globals are available in the Request::__construct()
• I believe the Request::__construct() should have more attributes like path domain and schema that abstracts the full absolute URI accorging to http://tools.ietf.org/html/rfc2616#section-5.1.2. The current uri attribtue would be renamed to path.
• The behavior should be the same for constructing a Request with custom params and importing from env vars.
• Request::response() should check if $this->route instanceof AbstractRoute instead of !$this->route
• Add RequestInterface and RouteInterface, change type checking to use them instead of concrete implementations
• Request::routineCall and other routine-related logic should move to AbstractRoute

[alganet]

Oops, didn't noticed @nickl- already started testing some things. Hey @nickl-, feel free to move any tests you want from tests/legacy/ to tests/library/.

I've started the tests using some conventions on tests, we should discuss them:

• Added @covers annotation. I'm a fan of single-line annotations like /** @covers SomeClass:someMethod */.
• Avoiding using "foo", "bar", "example" and generic things. I'm trying to use examples closer to the real world like "documents", "images", "stock-prices" and so on. This should make our tests more readable.
• My definition of unit is: each possible branch in a method execution stack. A method that can lead to 3 different execution flows should have 3 unit tests. There are hidden pitfalls everywhere, even type castings sometimes forks the execution flow.
• Testing method names using imperative descriptions (see the testdox sample below)

 [x] Is possible to construct using values from superglobals
 [x] Is possible to construct with custom method
 [x] Is possible to construct with custom uri
 [x] Absolute uris should be parsed to extract the path on constructor
 [x] Response is null without setting a route
 [x] Request is able to deliver a response without setting path params
 [x] Request is able to deliver a response using previously set path params

The idea is that each line on the testdox output should be descriptive enough to say how a specific unit behaves and what is being tested.

I've also added messages to all $this->assert lines, so when they fail the developer can understand better what the test is, instead of just blind-fix it to make it pass. Making the tests more understandable is a top priority.

I'm also exploring a nice idea from last night. We should be able to use test dependencies and data providers to explore combinatory tests (seems like the right choice for testing Routines, for example). It's a simple idea: a test is populated by a data provider, then another test is declared as dependent of the first one. For each provided data on the first, the second should run. I hope PHPUnit allows that someday, experiments so far on PHPUnit 3.6 were unsuccessful.

[alganet]

BTW, I'm starting with the tests for the Request class:

https://github.com/Respect/Rest/blob/develop/tests/library/Respect/Rest/RequestTest.php

[alganet]

Found these notes on PHPunit manual:

When a test receives input from both a @dataProvider method and from one or more tests it @Depends on, the arguments from the data provider will come before the ones from depended-upon tests.

When a test depends on a test that uses data providers, the depending test will be executed when the test it depends upon is successful for at least one data set. The result of a test that uses data providers cannot be injected into a depending test.

All data providers are executed before the first call to the setUp function. Because of that you can't access any variables you create there from within a data provider

http://www.phpunit.de/manual/3.6/en/writing-tests-for-phpunit.html

[augustohp]

Great things going on! Let's try and focus on better tests as @alganet and @nickl- are already doing, let's get the points to refactor here on this issue while we decide what to do with them.

Go go go unit tests! I will try to focus on some Routines tests.

[alganet]

Finished the tests for the Request class with 100% code coverage (no side effects, always using mocks).

I've added a lot of helpers to create mocks and generators. Maybe these mocks could be reused in another tests, perhaps we should create something that extends the PHPUnit_Framework_Testcase.

[alganet]

I've commited some annotations for PHPunit, phpDocumentor (maybe, not sure) and Respect\Doc. Please see this issue guys: Respect/Doc#16

[nickl-]

@alganet quoted phpunit documentation referring to @Depends.

I also had exactly the same idea as you when I stumbled on this @Depends:

a test is populated by a data provider, then another test is declared as dependent of the first one. For each provided data on the first, the second should run.

But alas it doesn't do any of that if anything at all as I couldn't even be sure that it actually runs test b before a. Also set-up and tear down does not work as previously advertised anymore and as far as the data providers go they seem to be loaded even before setup so you cannot even rely on the state.

I think wrapping is a good idea:

perhaps we should create something that extends the PHPUnit_Framework_Testcase.

We will need to ensure that it still runs as standard or configurable to include the custom wrappers from within the standard library I would imagine but the more control we can get for phpunit the better. I was also unable to make the --filter option work, for running a single test. I am not sure what is going on there. Differences between the text and html reports etc are the rewriting the tool or what?