New TestContext Feature

48 views
Skip to first unread message

Charlie Poole

unread,
Aug 1, 2010, 10:49:04 AM8/1/10
to nunit-...@googlegroups.com
Hi All,

This is an experimental feature, so the implementation is likely to
change a bit, but you can use it now. In fact, your use will drive any
future changes, so give it a try. At this time, it's not in the docs,
except for the Release notes. Here's a synopsis.

TestContext.TestName gives you the name of the current test case.
You can use this for logging. You could also use it in SetUp or
TearDown to make your tests very fragile and ugly. Please don't!

TestContext.Properties returns the properties dictionary associated
with the test. If you previously created an extension or used
reflection to access your own custom properties, you probably
don't need it any longer.

TestContext.State returns the current state of the text using the
TestState enumeration, which has the same values as the internal
ResultState enumeration. Check the intellisense for the values.

TestContext.Status returns the current test status using the
TestStatus enumeration, which is what we are using in NUnit 3.0.
For that reason, I suggest you use it rather than TestState. Again,
see the intellisense for the values.

While State and Status can be accessed in the SetUp or in the
test itself, they will always have the same value of Inconclusive.
Their real use is in a TearDown method, where you can determine
whether the test succeeded or failed and act accordingly.

The feature uses the thread CallContext. I believe it uses it in a
clean way, which won't cause problems in the future, but you should
be aware of this if any issues come up.

Right now, TestContext is entirely static, even though it pulls its
information from the thread context. This ain't pretty, but it's
TSTTCPW right now. I envision driving it to be thread local and
chaining from the current context to higher level contexts, but
first let's develop some ideas about what it needs to do.

There are a number of bits of ugly in it - like duplicating the
code for ResultState as TestState - due to the need to keep
nunit.core and nunit.framework separate. All this is bearable,
since it's going away in 3.0.

Thanks again to Kenneth for spiking this feature.

Charlie

Reply all
Reply to author
Forward
0 new messages