Source Changes

[Charlie Poole]

Hi All,

Two changes checked in that impact the NAnt build:

1) The default build is now .NET 2.0 rather than 1.1

2) The 1.x build no longer builds the Gui.

I have not yet removed the VS2003 solution - I want
to make sure it all works first.

Folks with .NET 1.x stuff to test, please try this
out from the Gui or console runner and let me know.

Here's how:

GUI

Run it and load your project or assembly. By default,
it will run under .NET 2.0. UseTools | Settings to
set it to load with .NET 1.1 or 1.0 and run your tests
that way. You can use Tools | Test Assemblies to see
how a separate process is being launched to run your
tests.

Alternatively, if you have a .nunit project, edit it
to specify running under .NET 1.1 or 1.0.

CONSOLE

Either edit your NUnit file under the Gui first or
manually add runtimeFramework="v1.1" (or 1.0) to
the Config element.

Alternatively, simply use the /framework option.
For example: /framework:net-1.1.

It will help move things along much more quickly
if I can get some feedback on this.

Charlie

[Olof Bjarnason]

2009/3/3 Charlie Poole <cha...@nunit.com>

.. and I would if I could ... Just haven't used .NET1.1 in like four years :)

Charlie

--
Min blogg:
http://olofb.wordpress.com
[My blog, in Swedish]

[Charlie Poole]

Hi Olof,

 

Well, if nobody is using it I'll just not worry about it!

 

Charlie

---

From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com] On Behalf Of Olof Bjarnason
Sent: Tuesday, March 03, 2009 11:14 AM
To: nunit-...@googlegroups.com
Subject: [nunit-discuss] Re: Source Changes

[Olof Bjarnason]

2009/3/3 Charlie Poole <cha...@nunit.com>

Hi Olof,

 

Well, if nobody is using it I'll just not worry about it!

If I were maintaining a legacy .NET1.1 app with NUnit tests -- I'd never dare to upgrade NUnit anyway.

It's just a rule of thumb for large, old systems - dont upgrade _anything_ :)

[Charlie Poole]

Good point! That seems to be the way most .NET tools work anyway, the

big exception being that VS2008 can build for both 2.0 and 3.5.

 

For NUnit 3.0, I imagine we'll have frameworks for 1.x but won't

be adding features to them. At some point, the 2.0 feature set will

get frozen as well and we'll only have 3.5 and 4.0.

 

For NUnit 2.5, it doesn't seem like we're there yet.

 

Charlie

---

From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com] On Behalf Of Olof Bjarnason

Sent: Tuesday, March 03, 2009 11:53 AM

[Jamie Cansdale]

Hi Charlie,

> Run it and load your project or assembly. By default,
> it will run under .NET 2.0. UseTools | Settings to
> set it to load with .NET 1.1 or 1.0 and run your tests
> that way.
>

Rather than having it default to .NET 2.0, how about making the
default be the target assembly's 'ImageRuntimeVersion' property? This
way it would default to execute test using the same runtime the they
were built with.

I think this would make sense when executing legacy .NET 1.1
assemblies and for the soon to be released .NET 4.0 assemblies. I'm
pretty sure that having an explicit setting for this feature would
discourage its use.

Regards,
Jamie.

--
http://www.testdriven.net
http://weblogs.asp.net/nunitaddin

[Charlie Poole]

Hi Jamie,

I mis-spoke. The default is "the same version under which
the gui is running" which could be higher than 2.0.

Let's run through the alternatives...

If you specify the framework to use on the command line
or in the .nunit project, then that's what we use.

If you don't specify, we need a default. The NUnit
settings control the default. The "default default"
is Any, which means you can run under whatever
runtime is already in use for NUnit itself.

You're suggesting we look at the assembly first. I
assume you mean when we load a single assembly, not
a project, right? A project could contain assemblies
built with different versions of the CLR - unusual
but possible.

For a single assembly, we could easily make that
check. We could even do it for a project with a
single assembly, but it's a tad messy, so I think
I would prefer that projects specify how the
runtime they want to use, if they care.

The only problem I see with this is how we might
override this default to test - for example - a
.NET 1.1 assembly under .NET 2.0.

Charlie

> -----Original Message-----
> From: nunit-...@googlegroups.com
> [mailto:nunit-...@googlegroups.com] On Behalf Of Jamie Cansdale
> Sent: Tuesday, March 03, 2009 12:27 PM
> To: nunit-...@googlegroups.com
> Subject: [nunit-discuss] Re: Source Changes
>
>

[Fabio Maulo]

Charlie,
IMHO you should close NET1.1 compatibility, release 2.5 ASAP, begin
3.0 compatible only with NET3.5 or above (4.0 is coming).
3.5 give us the ability to use a lot of new features and simplify/
improv the syntax:
actual.Should.Be.EqualTo(5); // if actual is int
actual.Should.Be.EqualTo(new[]{1,2,3}); // if actual is
IEnumerable<int>
actual.Should.Contains("something"); // if actual is
IEnumerable<string>
actual.Should.Be.XmlSerializable();
Expect.Action(()=> DoSomething()).Throws<ArgumentNullException>
().WithMessage.StartingWith("My exception message");
Expect.Class<MyClass>().MarkedWith<MyAttribute>();
Expect.Method(() => myClass.AMethod()).MarkedWith<MyAttribute>();
Expect.Property(() => myClass.AProperty).MarkedWith<MyAttribute>();
and so on....

I know how much effort you are putting in NUnit back draw
compatibility but... do you really think that it is useful ?
How many people are updating NUnit to use it in .NET1.1 ?

I love NUnit and I hope it continue as "standard de Facto", even
including some other concept as NBehave or NSpec... at the end, who
said that we can't use NUnit to test behavior or something else ?

On 3 mar, 17:12, "Charlie Poole" <char...@nunit.com> wrote:
> Good point! That seems to be the way most .NET tools work anyway, the
> big exception being that VS2008 can build for both 2.0 and 3.5.
>
> For NUnit 3.0, I imagine we'll have frameworks for 1.x but won't
> be adding features to them. At some point, the 2.0 feature set will
> get frozen as well and we'll only have 3.5 and 4.0.
>
> For NUnit 2.5, it doesn't seem like we're there yet.
>
> Charlie
>
>   _____  
>

> From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com]
> On Behalf Of Olof Bjarnason
> Sent: Tuesday, March 03, 2009 11:53 AM
> To: nunit-...@googlegroups.com
> Subject: [nunit-discuss] Re: Source Changes
>

> 2009/3/3 Charlie Poole <char...@nunit.com>

>
> Hi Olof,
>
> Well, if nobody is using it I'll just not worry about it!
>
> If I were maintaining a legacy .NET1.1 app with NUnit tests -- I'd never
> dare to upgrade NUnit anyway.
>
> It's just a rule of thumb for large, old systems - dont upgrade _anything_
> :)
>
> Charlie
>
>   _____  
>

> From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com]
> On Behalf Of Olof Bjarnason
> Sent: Tuesday, March 03, 2009 11:14 AM
> To: nunit-...@googlegroups.com
> Subject: [nunit-discuss] Re: Source Changes
>

> 2009/3/3 Charlie Poole <char...@nunit.com>

[Fabio Maulo]

Ah... to explain a little more...

I have some projects which target is .NET2.0 but in test project I'm
using .NET3.5 because I need Linq and Moq for example.
Since NET2.0, more actualized is the test-environment and better I can
test my project.

[Charlie Poole]

Hi Fabio,

> Charlie,
> IMHO you should close NET1.1 compatibility, release 2.5 ASAP,
> begin 3.0 compatible only with NET3.5 or above (4.0 is coming).

I think 4.0 will be the big point of change, because 3.0 and
3.5 are only 2.0 with extra assemblies. That's why current
plans are to base NUnit on 2.0. Of course, I made those plans
a long time back and maybe they should change now.

But when I say "NUnit" is based on 2.0, I mean the gui and console
runners and the code that loads and executes tests, not the framework
itself, which you use to write your tests.

In 3.0, we will have multiple frameworks, for testing under each
version of .NET. We started that in 2.5, with separate frameworks
for 1.0/1.1 and 2.0/3.0/3.5 for the first time - older versions
had two downloads, but they contained the same code. In NUnit 3.0,
I imagine that we will have 1.0/1.1, 2.0/3.0 and 3.5 frameworks
initially, with a 4.0 framework following pretty quickly.

In addition to the frameworks, NUnit 2.5 has (and 3.0 will
continue to have) a small exe stub for running tests in
a separate process under each framework. This is currently
called nunit-agent.exe.

So, I expect to have continued "support" for old frameworks
without any drawback to the new frameworks. The older versions
will be frozen as far as features go so there will no longer
be a drawback with respect to taking time to update them.

Of course, the alternative is to just tell people they have
to use an older version of NUnit, as Microsoft does with
Visual Studio. That always annoyed me. :-)

> 3.5 give us the ability to use a lot of new features and
> simplify/ improv the syntax:
> actual.Should.Be.EqualTo(5); // if actual is int
> actual.Should.Be.EqualTo(new[]{1,2,3}); // if actual is
> IEnumerable<int>
> actual.Should.Contains("something"); // if actual is
> IEnumerable<string>
> actual.Should.Be.XmlSerializable();
> Expect.Action(()=> DoSomething()).Throws<ArgumentNullException>
> ().WithMessage.StartingWith("My exception message");
> Expect.Class<MyClass>().MarkedWith<MyAttribute>();
> Expect.Method(() => myClass.AMethod()).MarkedWith<MyAttribute>();
> Expect.Property(() => myClass.AProperty).MarkedWith<MyAttribute>();
> and so on....

There seems to be disagreement about use of extension methods to
improve test syntax. I think we would need to keep the older
(Assert.That) syntax around as well and let people choose.

> I know how much effort you are putting in NUnit back draw
> compatibility but... do you really think that it is useful ?
> How many people are updating NUnit to use it in .NET1.1 ?

Probably not so many, I agree. I'm removing the VS Build and
converting (finally) all the Gui to .NET 2.0. The 3.0 plan
shows a WPF-based Gui, but I suspect the old one will be
with us for a while, since it works and the actual testing
features are more important to most folks - unless somebody
wants to write it, of course!

> I love NUnit and I hope it continue as "standard de Facto",
> even including some other concept as NBehave or NSpec... at
> the end, who said that we can't use NUnit to test behavior or
> something else ?

I imagine a BDD-like framework being a separate assembly from
the nunit.framework, but inheriting the basic concepts of
test constraints and reporting from it.

I do agree with your overall suggestion that we get 2.5 out
of the way as soon as possible and move on to 3.0!

Charlie

[Charlie Poole]

Hi Fabio,

> Ah... to explain a little more...
>
> I have some projects which target is .NET2.0 but in test
> project I'm using .NET3.5 because I need Linq and Moq for example.
> Since NET2.0, more actualized is the test-environment and
> better I can test my project.

Have you encountered any problems with using the 2.0-based
version of NUnit with Linq and Moq? Especially anything we
should fix in 2.5?

Charlie

[Fabio Maulo]

On 6 mar, 14:47, "Charlie Poole" <char...@nunit.com> wrote:
> Have you encountered any problems with using the 2.0-based
> version of NUnit with Linq and Moq? Especially anything we
> should fix in 2.5?

No, nothing so far. If you have a counter for 2.5 downloads you can be
pretty sure that each one are using 2.5 with NET3.5.

[Charlie Poole]

Hi Fabio,

> No, nothing so far. If you have a counter for 2.5 downloads you can be
> pretty sure that each one are using 2.5 with NET3.5.

That's probably true, but lots of people are still using 2.0
in their IT departments. I base that on my coaching experience.
I agree that 1.x is limited to legacy apps now, and most of them
will run OK under 2.0 anyway.

Of course, they could still do that using older releases of
NUnit. But I'd like to attract them to 3.0 and make it easier
for them to convert.

Charlie

>
> >
>

[Fabio Maulo]

On 6 mar, 15:29, "Charlie Poole" <char...@nunit.com> wrote:
>
> Of course, they could still do that using older releases of
> NUnit. But I'd like to attract them to 3.0 and make it easier
> for them to convert.

I think that, for tests, have an 3.5 prj is not a big deal.

Well... what I really think is that even my mother-in-law has .NET3.5
installed in his PC even if she don't know what this mean.

[Sébastien Lorion]

I wouldn't be so sure of that ... Lots of organizations have a big reticence to change, almost a phobia. And unfortunately, in our industry, it is usually the management that decides which tools we should use to do our job.

Sébastien

[Mark Levison]

Sébastien - you have me laughing. Frequently that's true. In my current coaching role management is onside with my recommendations but we have one developer who raises FUD over any new technology. Its strange to see the world turned on its ear.

Mark

--
Cheers
Mark Levison
Blog: http://www.notesfromatooluser.com/
Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html

[Charlie Poole]

It's true that many orgs are foolishly hesitant to change but I've also coached

in some companies where changes were thrown in without any planning or

thought for the impact. Imagine for example a medical device where the

developers suddely decide to use a newer framework version - but the

older architecture was already reviewed for FDA compliance. The

company would have to spend a lot of money to re-validate the device

and its software. In that case, it's the change advocates who are foolish.

 

I'll allow that for most business apps, it makes sense to use new technology

if it makes your job easier and if the team is able to understand and absorb

it quicly enough. I did see one team introduce four or five new technologies

simultaneously, however. They suffered. :-)

 

Charlie

---

From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com] On Behalf Of Sébastien Lorion
Sent: Friday, March 06, 2009 11:14 AM

To: nunit-...@googlegroups.com
Subject: [nunit-discuss] Re: Source Changes

[Sébastien Lorion]

Well, yes, abuse can go one way or the other. My answer was tainted by my current contract ...

Usually that kind of company also have an IT department that acts as a dictator and which only apparent reason to live is to make you suffer for ever wanting to change your desktop background. It cannot be worse than Japan tho. I was once told that my chair was not at the standard height :p

Sorry for the OT bit :-D

Sébastien

[Jamie Cansdale]

Hi Charlie,

Sorry about the late replay!

> You're suggesting we look at the assembly first. I
> assume you mean when we load a single assembly, not
> a project, right?
>

Yes, I'm suggesting when we load a new test assembly we take the
runtime setting from the version of .NET it was compiled with. I guess
this setting could get persisted if the user decides to save the
configuration as a (.nunit) project. Doing this check when loading a
project would be unnecessary.

I'm concerned about the situation where a user is unwittingly
executing their unit tests using .NET 2.0, but their application using
.NET 1.1 when launched from Visual Studio 2003. They could end up with
components of their application failing because their tests pass when
executed with .NET 2.0, but not when executed with .NET 1.1.

You could argue that not many people are using Visual Studio 2003 with
the latest version of NUnit. However, we're soon going to end up in
the same situation with Visual Studio 2010 and .NET 4.0. Tests should
default to executing with .NET 4.0 when they've been built with .NET
4.0.

Regards,
Jamie.

--
http://www.testdriven.net

http://twitter.com/jcansdale
http://weblogs.asp.net/nunitaddin



2009/3/3 Charlie Poole <cha...@nunit.com>: