Bug #10467
CodeCoverage: should data/temporary be ignored?
Status: | Resolved | Start date: | 2010-10-26 | |
---|---|---|---|---|
Priority: | Must have | Due date: | ||
Assigned To: | Karsten Dambekalns | % Done: | 100% |
|
Category: | - | |||
Target version: | - |
Description
Currently the testing web controller has a flag to enable code coverage.
However the code coverage is correctly limited to the package we are testing (working as intended). But: The code coverage seems to consume the data/temporary folder too. The manual says that unit testing should be done by calling constructors directly and not using any aop proxies but using mock objects and injecting them into the tested classes. That's rather fine.
Due to a bug within phpunit itself currently the code coverage feature will report notices as soon as it sees the data/temporary package. PHPUnit was fixed.
See http://lists.typo3.org/pipermail/flow3-general/2010-October/000603.html
See PHPUnit issue at http://github.com/sebastianbergmann/phpunit/issues/closed#issue/54
I suggest updating Flow3's PHPUnit package. And maybe the data directory should be blacklisted so that PHPUnit does not try code coverage on the temporary data.
Associated revisions
[+BUGFIX] Testing: Fix code coverage collection in web testrunner
The use of blacklisting lead to proxies being included in code coverage
collection. Switched to a whitelisting approach.
In addition the AbstractTestRunner has been removed.
Change-Id: I4d7179a8c80c88f17054d073c4fea33cdce0dbc8
Fixes: #10467
History
#1 Updated by Karsten Dambekalns over 4 years ago
- Status changed from New to Accepted
- Assigned To set to Karsten Dambekalns
- Target version set to 1.0 alpha 13
- % Done changed from 0 to 80
We no longer use the PHPUnit FLOW3 package, but rely on PHPUnit 3.5 (at least). In addition the configuration for PHPUnit when used from the command line or through Phing makes correct use of whitelisting now.
The web test runner, well, it should be adjusted, probably.
#2 Updated by Karsten Dambekalns over 4 years ago
- Status changed from Accepted to Under Review
#3 Updated by Karsten Dambekalns over 4 years ago
- Status changed from Under Review to Resolved
- % Done changed from 80 to 100
Applied in changeset 5bc52fa846834316244fda0c9c6f2364ea6690e8.
#4 Updated by Karsten Dambekalns about 4 years ago
- Target version deleted (
1.0 alpha 13)