New Gem sharptestsex - Fluent assertions for your tests.

[Chris Edwards]

I just added SharpTestsEx 1.0.0.0 RTM gem to rubygems.org.
http://rubygems.org/gems/sharptestsex

I bundled NUnit and xunit dlls into the deployment since they were
optional. Didn't know if it was a good idea to install the
dependencies if they weren't required. For instance I use NUnit 2.5.7
with SharpTestsEx, but if I used the NUnit-specific version, I would
need to use 2.5.5. If there is a more accepted way to handle optional
dependencies, I'll be glad to modify the gemspec.

-Chris

http://chrisedwards.dreamhosters.com/

[Brendan Erwin]

I'm currently working on the dependency leveling/conflict resolution behavior for Nu.
If there is a third-party dependency that a gem has, it _must_ reference it as a dependency in the gem, otherwise there will be no way for Nu to resolve conflicts.

I think I've seen the concept of meta gems to include options. i.e. there is already an NUnit gem, so make a sharptests gem without either of the optional pieces, then a sharptests+nunit gem that includes a dependency on sharptests and nunit. You might give that a go.

(BTW, thanks for doing this one! I've been hoping to see sharptestsex packaged up.)

[Charlie Poole]

Some sort of "optional dependency" would help - assuming that gems don't
already have that.

Charlie

[Eric Hexter]

This gem name is a good argument for using pascal casing... sharpTestSex or sharpTestsEx

[Rob Reynolds]

;)
Gems are always lower case by convention.

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[Brendan Erwin]

Underscores. They make life better. 

Sent from my iPhone

[Rob Reynolds]

Or dashes...
:)
I'm coming around to dashes. Bil has a convincing argument for castle-core over castle.core.

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[Justin Rudd]

Of course all UPPERCASE doesn't work any better...

Anyone remember shell extension programming??  SHITEMID :)  Of course after working with them, the name was quite appropriate :)

[Brendan Erwin]

Dashes for namespace dots, underscores for word separation?

so: some_namespace-assembly_name

then we'd have, castle-core and sharp_tests_ex

It'd be confusing to try and infer the rule from examples, but once you know the rule I think this would be pretty nice. (it would also enable searching tricks like "castle-" for all the castle projects)

[Chris Edwards]

I updated the sharptestsex gem to only include the framework-
independent version of the dll.
I added a sharptestsex-nunit gem that included the nunit-specific
version plus the dependency.
I started to add sharptestsex-xunit, but realized that the xunitnet
gem already exists, but does not have the version I need. Should I add
it myself? If not, do I contact the project owners? I am guessing
someone else added the gem, and not the owner of the project.

-Chris

http://chrisedwards.dreamhosters.com/

[Chris Edwards]

Yeah, I noticed that CodePlex resolved that in their url with
http://sharptestex.codeplex.com/ making test singular rather than
plural. I chose to use the actual library's dll name since it was
probably what people would type if they were trying to install it from
the command line.

-Chris

On Sep 11, 11:21 am, Eric Hexter <eric.hex...@gmail.com> wrote:
> This gem name is a good argument for using pascal casing... sharpTestSex or
> sharpTestsEx
>
> On Fri, Sep 10, 2010 at 11:46 PM, Chris Edwards

> <chrisedwards...@gmail.com>wrote:

[Chris Edwards]

I thought about packaging it up as multiple gems. The other thought
would be to not include the dependencies. In the case where the user
decides to use the NUnit-specific dll, they are obviously using NUnit
so it should exist. They may, however, get an error if they are using
the wrong version of NUnit.

This versioning problem arises from the fact that we are distributing
binaries and not code. That being said, I understand why we are doing
this--distributing code is a far more complex problem. Distributing
binaries simplifies the problem, but it introduces its own
complexities. When distributing code, we only care about the version
of the library itself. When distributing binaries, we are concerned
with the version of the library, AND the version of each of the
dependencies it was compiled against. We could have
sharptestsex_nunit-2-5-5 and sharptestsex_nunit-2-5-7. It really gets
nasty when you have multiple dependencies, however we encounter this
issue whether we use a package manager or not. I know I have to build
some OSS projects from source just so I can use the latest version of
one of their dependencies. Its a bigger problem than I first thought.

Back to the main topic. One of the reasons I was afraid to put the
dependency in the gem was that I feared it would downgrade the version
of NUnit I was using...even if I wasn't using the NUnit-specific libs.
So if I was using NUnit 2.5.7, then installed SharpTestsEx that
depended on NUnit 2.5.5, I would end up with 2.5.5 even if I didn't
want to use the dll that depended on NUnit.

I think for now I will package it up as multiple gems. One that is
framework independent, and one for each framework with the specified
framework dependency.

-Chris

http://chrisedwards.dreamhosters.com/


On Sep 11, 1:27 am, Brendan Erwin <brendanjer...@gmail.com> wrote:

[Brendan Erwin]

Yes, work with the publisher to get the version you need out there.

Sent from my iPad

[Rob Reynolds]

This is also why we only package releases. A release is a specific point in time with specific dependencies.

So your sharptestsex-nunit v1.2.3 (made up version) is version 1.2.3 of sharptestsex and it has a dependency on say nunit 2.5.5. sharptestsex-nunit v1.2.4 may have a dependency on nunit 2.5.7. But it's two releases/versions of the same gem, not two different gems.

sharptestsex-nunit
- v1.2.3 (dependency on nunit 2.5.5)
- v1.2.4 (dependency on nunit 2.5.5)

These dependencies are decided by the project committers, not the users. When you are a user of the gem, you get presented with options when you have a different version of nunit versus what the version of sharptestsex requires. You have to then choose to downgrade nunit, try to use the different versions and manually resolve the incompatibilities, or not use the new library you wanted to import. This feature of nu is what we are working on now. Right now it should automatically downgrade nunit to the version the library requires.

Does all this make sense?

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[Chris Edwards]

Yes. Makes total sense. And after my post, I read through the issues
list and some of the prior discussion on this one and see where this
has already been discussed at length. I should have read a bit
first...

I'll contact the xunit guys on this one.

-Chris

On Sep 12, 10:55 am, Rob Reynolds <ferventco...@gmail.com> wrote:
> This is also why we only package releases. A release is a specific point in
> time with specific dependencies.
>
> So your sharptestsex-nunit v1.2.3 (made up version) is version 1.2.3 of
> sharptestsex and it has a dependency on say nunit 2.5.5. sharptestsex-nunit
> v1.2.4 may have a dependency on nunit 2.5.7. But it's two releases/versions
> of the same gem, not two different gems.
>
> sharptestsex-nunit
> - v1.2.3 (dependency on nunit 2.5.5)
> - v1.2.4 (dependency on nunit 2.5.5)
>
> These dependencies are decided by the project committers, not the users.
> When you are a user of the gem, you get presented with options when you have
> a different version of nunit versus what the version of sharptestsex
> requires. You have to then choose to downgrade nunit, try to use the
> different versions and manually resolve the incompatibilities, or not use
> the new library you wanted to import. This feature of nu is what we are
> working on now. Right now it should automatically downgrade nunit to the
> version the library requires.
>
> Does all this make sense?
>
> ____
> Rob
> "Be passionate in all you do"
>

> http://devlicio.us/blogs/rob_reynoldshttp://ferventcoder.comhttp://twitter.com/ferventcoder

[Charlie Poole]

Hi Rob,

> Right now it should automatically downgrade nunit to the
> version the library requires.

This raised a question in my mind. I hope when you say "downgrade"
you mean only in the scope of the current project and not globally.

Charlie

[Rob Reynolds]

Yep, just current project.

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder