It seems like adding a new capability to AssemblyFixture would be a useful enhancement. Something similar to using a FixtureSetUp/TearDown or SetUp/TearDown method on the AssemblyFixture, but that would run before/after each Test of each TestFixture.
On Aug 10, 9:58 pm, Mark Kharitonov <[email protected]> wrote: > TestRunnerExtension seems more relevant. > Thanks. > > On 10/08/2010, at 22:24, Graham Hay wrote: > > > > > You have a multitude of options! :) If you want it to happen for > > every test, you could write a TestRunnerExtension. There's an > > example in gallio\src\Gallio\Gallio\Runner\Extensions > > \DebugExtension.cs. You can hook into the TestStepStarted event and > > write to your log. Alternatively, if you're only interested in > > specific tests, you could create an attribute inheriting from > > TestAttribute and "decorate" the test with your logging code: > > > public class LoggedTestAttribute : TestAttribute > > { > > protected override void Execute(PatternTestInstanceState > > state) > > { > > // log test begin > > state.InvokeTestMethod(); > > // log test complete > > } > > } > > > On 30 July 2010 22:04, Mark Kharitonov <[email protected]> > > wrote: > > Hi. > > > We test a client server application (so one may call our tests as > > integration tests rather than unit tests). Anyway, in the test > > environment, the client is the unit test engine (Gallio, in this case) > > and the server is our production server with unit test extensions (to > > run test specific commands). > > > I would like to have the full name of the current test (including the > > current parameters, just like Gallio defines it) to appear in the > > server side log immediately after the particular test starts and > > before it ends. I can invoke the relevant command from the [SetUp] and > > [TearDown] methods of a fixture, but we have many fixtures and they do > > not have a base class - there was no need for it. So, as I see it, > > there are two obvious options: > > - Introduce a new base class just to deal with this logging issue and > > then make all the [SetUp] and [TearDown] methods override the base > > version, which will do the logging. > > - Duplicate the logging code in the [SetUp] and [TearDown] methods of > > each fixture. > > > I dislike both options. Is there a better way? > > > Thanks. > > > -- > > You received this message because you are subscribed to the Google > > Groups "MbUnit.User" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to mbunituser > > [email protected]. > > For more options, visit this group athttp://groups.google.com/ > > group/mbunituser?hl=en. > > > -- > > You received this message because you are subscribed to the Google > > Groups "MbUnit.User" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to mbunituser > > [email protected]. > > For more options, visit this group athttp://groups.google.com/ > > group/mbunituser?hl=en. > > ======================================================================== > == > There are two kinds of people. Those whose guns are loaded and those > who dig. > > (The good, the bad and the ugly). > So let us raise our cups for our guns always be loaded. -- You received this message because you are subscribed to the Google Groups "MbUnit.User" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mbunituser?hl=en.
