| 2013-10-28 02:57:18 |
Charlie Poole |
description |
In many cases a bug is reported to a project along with the unit test. The unit test needs to be integrated, but it may take some time before it can be resolved. In this case, it isn't clear what its state should be:
* If it is integrated as is, the unit test fails and causes the whole build to fail. This hinders development on other features and bugs - it's hard to know whether a red unit test represents a regression or just an unrelated open bug.
* [Ignore] seems like the current best solution, but is semantically unclear. Tests can be [Ignore]d for many reasons (temporary breakage) and sometimes remain that way for a long time.
A [KnownBug] mark would semantically handle this, and would effectively create an "open bug list" within the test suite. It would also allow GUIs to visually indicate the state as distinct from [Ignore].
If this seems like a good idea I'll be happy to submit a patch. |
[Issue now tracked at https://github.com/nunit/nunit-framework/issues/44]
In many cases a bug is reported to a project along with the unit test. The unit test needs to be integrated, but it may take some time before it can be resolved. In this case, it isn't clear what its state should be:
* If it is integrated as is, the unit test fails and causes the whole build to fail. This hinders development on other features and bugs - it's hard to know whether a red unit test represents a regression or just an unrelated open bug.
* [Ignore] seems like the current best solution, but is semantically unclear. Tests can be [Ignore]d for many reasons (temporary breakage) and sometimes remain that way for a long time.
A [KnownBug] mark would semantically handle this, and would effectively create an "open bug list" within the test suite. It would also allow GUIs to visually indicate the state as distinct from [Ignore].
If this seems like a good idea I'll be happy to submit a patch. |
|
