PNUnit 2.5.2 - Incomplete report when running TestFixture with multiple TestCases

[Keld Ølykke]

PNUnit will run .conf files where the <TestToRun> may point to a test case, a test fixture or simply a namespace containing test fixtures.

However, Asserts and Exceptions are only reported in smoke-errors.log if <TestToRun> points at a test case (method w. Test-attribute). If <TestToRun> points at TestFixture or a namespace the exceptions and asserts are not reported.

Kind Regards,

Keld Ølykke

[Keld Ølykke (oelykke)]

Note! Wrong version - should have been 2.6.2.

[Charlie Poole (charlie.poole)]

I believe your initial statement is incorrect. PNUnit is only intended to
run test methods.

I'll have to check this in the code and docs, however, since I haven't
looked at it for a while.

Assuming I'm right, there still may be a bug, however. PNUnit shouldn't
simply fail to report exceptions if a fixture or namespace is specified.

Charlie

On Mon, Dec 17, 2012 at 1:40 AM, Keld Ølykke <email address hidden> wrote:

> Note! Wrong version - should have been 2.6.2.
>
> --
> You received this bug notification because you are subscribed to NUnit
> Extended Testing Platform.
> https://bugs.launchpad.net/bugs/1091138
>
> Title:
> PNUnit 2.5.2 - Incomplete report when running TestFixture with
> multiple TestCases
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunitv2/+bug/1091138/+subscriptions
>

[Keld Ølykke (oelykke)]

> ... PNUnit is only intended to
run test methods.

Ok. That makes sense then. I know it was meant for client server tests and I guess it then makes sense that the launcher synchronizes each agent with a test method.

On the other hand, the cumbersome part of PNUnit right now is the .conf files and getting the results back into a report.
Support for TestFixtures and namespaces could lighten the .conf files a bit.

As a side info we we generate the .conf files using reflection on the test assembly. We do it like this since we have .conf files dependent on number of cores on target CPU (to avoid timeouts) and the programmer really shouldn't waste time on keeping the .conf files updated. We use the TimeOut attribute and a few custom attributes to bundle tests together to optimize running time since the Launcher waits for all agents to complete a batch of tests. In our case it would be awesome if the Launcher kept the agents busy, but I can see that this doesn't really match the current design.

In any case thumbs up for an interesting piece of software that is currently closing a gap in the world of automated tests.