Sorry, "Passing the NUnit output"...
On 6/7/07, Evan Worley <[EMAIL PROTECTED]> wrote:
Passing the NMaven output to the console is fairly trivial, I did it a few
days ago. If I remember correctly, when you invoke the CommandLine you can
specify a StreamConsumer which will consume the lines of output from the
CommandLine. We can pipe the input that the consumer receives to the maven
console. I think the more involved task it getting the nunit output where
we want it.
Evan
On 6/7/07, Shane Isbell <[EMAIL PROTECTED]> wrote:
>
> All of the NUnit code is under a zlib license, so we can modify the
> nunit-console to do what we want. The issue of how we get .NET output to
> the
> output console that Maven is using is a general one that we haven't
> tackled
> yet. The IDE gets Maven output by using socket loggers, so that is one
> approach. I think this is also where log4net may come into play,
> allowing us
> to use different appenders to output to sockets, messaging systems, etc,
> for
> logging interoperability.
>
> Shane
>
>
> On 6/6/07, Evan Worley <[EMAIL PROTECTED]> wrote:
> >
> > Brett,
> >
> > I think you are right on with the two important issues being how to
> > identify
> > the tests and the execution model for running the tests. One of the
> > difficulties in real-time reporting for NMaven is that the
> nunit-console
> > either spits to the console or can redirect all of the output to
> file. In
> > the later case we wouldn't be able to report until after all tests are
> > done,
> > which doesn't add much value. In the case of extracting the info to
> > report
> > from the console, parsing particular strings seems a bit fragile. It
> > seems
> > that we need some sort of bridge, essentially a NUnit-Runner for java.
> >
> > It seems as long as we rely on running nunit-console to execute our
> nunit
> > tests, it will be difficult to neatly plug into surefire.
> >
> > Thoughts?
> > Evan
> >
> > On 6/5/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> > >
> > > Yeah, it's going to take a close look and possibly surefire changes
> > > (though this is the best time to make them) if it is feasible at
> all.
> > > At first glance, it looks possible to me.
> > >
> > > The key things are really that:
> > > a) it can identify where the test sets are from java.
> > > b) how the forking of the test execution is going to work.
> > >
> > > Currently the forking is (just) out of alignment with where you'd
> > > want it for NMaven. You'd want it to do that and only run the tests
> -
> > > but currently the reporting happens in the forked instance too.
> > >
> > > This isn't critical, as we could get around this by forcing the
> > > surefire plugin to "never" fork and just fork inside the test
> > > executor - if that works out we could look at shifting the design in
> > > surefire and that would give nunit tests the ability to do fork
> once,
> > > fork always (instead of what I assume will be fork always
> otherwise).
> > >
> > > wdyt?
> > >
> > > - Brett
> > >
> > > On 06/06/2007, at 10:40 AM, Evan Worley wrote:
> > >
> > > > So I looked into this briefly and it seems that the current
> surefire
> > > > providers rely heavily on java reflection. We will be working
> with
> > > > nunit
> > > > tests on which we cannot use java reflection. Does anyone have
> any
> > > > idea how
> > > > we might wrap nunit as a surefire provider? Currently the nunit
> > > > plugin
> > > > invokes a command line which runs the nunit binaries and logs/
> > > > analyzes the
> > > > results.
> > > >
> > > > Thanks for any help,
> > > > Evan
> > > >
> > > > On 6/4/07, Evan Worley <[EMAIL PROTECTED] > wrote:
> > > >>
> > > >> Interesting question, I have just been manually transforming the
> > > >> nunit
> > > >> output to look like the junit. However if we could squeeze nunit
>
> > > >> into a
> > > >> surefire provider, that would be that much better.
> > > >>
> > > >> When you are building the same component in java and C#, these
> > > >> inconsistencies are very noticeable, so it would be great to have
>
> > > >> both
> > > >> platforms build output consistent.
> > > >>
> > > >> I will look into a nunit surefire provider.
> > > >>
> > > >> Thanks,
> > > >> Evan
> > > >>
> > > >> On 6/4/07, Brett Porter <[EMAIL PROTECTED] > wrote:
> > > >> >
> > > >> > I question I'd been meaning to ask - is it possible to fit
> nunit in
> > > >> > as a surefire provider instead of a separate plugin?
> > > >> >
> > > >> > This automatically buys this plus reporting integration.
> > > >> >
> > > >> > - Brett
> > > >> >
> > > >> > On 05/06/2007, at 1:32 PM, Evan Worley wrote:
> > > >> >
> > > >> > > Hi All,
> > > >> > >
> > > >> > > I was thinking there would be some value in doing some work
> on
> > > >> the
> > > >> > > nunit
> > > >> > > plugin to add some output similar to the junit
> plugin. Currently
> > > >> > > when nunit
> > > >> > > tests run, all the output is logged to file. It is not too
> much
> > > >> > > fun when
> > > >> > > your tests run for a few minutes, you see nothing. Here is a
>
> > > >> junit
> > > >> > > output
> > > >> > > vs nunit output comparison
> > > >> > >
> > > >> > > -- JUNIT --
> > > >> > > Running package1.TestClass1
> > > >> > > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed:
> > > >> > > 0.016 sec
> > > >> > > Running package2.TestClass2
> > > >> > > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed:
> > > >> > > 0.031 sec
> > > >> > > .
> > > >> > > .
> > > >> > > .
> > > >> > > Results :
> > > >> > >
> > > >> > > Tests run: 139, Failures: 0, Errors: 0, Skipped: 0
> > > >> > >
> > > >> > > -- NUNIT --
> > > >> > > NMAVEN-040-000: Executed command: Commandline = nunit-console
> > > >> C:\dev
> > > >> > > \project
> > > >> > > \main\component\target\test-assemblies\Namespace.Artifact.dll
> /
> > > >> out
> > > >> > > {SOME_OUTPUT_FILE} /err {SOME_OUTPUT_FILE}, Result = 0
> > > >> > >
> > > >> > > So I propose not logging the nunit stdout/stderr but rather
> > > >> > > reformatting and
> > > >> > > displaying it like the junit plugin does.
> > > >> > >
> > > >> > > Thoughts?
> > > >> > > Evan
> > > >> >
> > > >>
> > > >>
> > >
> >
>
