Contribution Proposal: NUnit.StaticExpect

[ChrisMaddock]

NUnit.StaticExpect is a library originally written for an in-place replacement of the AssertionHelper syntax - which we are currently considering removing from the framework.

As opposed to the original outdated AssertionHelper class, NUnit.StaticExpect has been expanded to wrap the NUnit's Assert.That calls - essentially providing a full, alternative syntax for utilising NUnit Constraints. I would personally consider the new project as an alternative syntax - which conveniently happens to also offer an almost drop-in replacement for the deprecated AssertionHelper class.

@fluffynuts is the current maintainer of this project - the project has already attracted external contributions from other interested users. We previously considered forking the AssertionHelper into a separate project within the organisation - and @fluffynuts has expressed interest in bringing NUnit.StaticExpect into the organisation in the same way.

I'd like us to consider bringing NUnit.StaticExpect into the organisation as a Contributed Project. Below are the criteria we previously discussed regarding bringing a new project into the organisation:

The primary criterion for acceptance is that the project should conform to our vision and values for NUnit and should be "better off" in some sense as a part of the NUnit Project rather than being maintained separately. We don't consider giving the project a publicity boost as a sufficient reason for accepting it, as there are other ways we can do that.

Based on this, below are a few reasons I personally think NUnit.StaticExpect would be a good fit for the org:

• We have a long term aim to support external constraint libraries for the framework. Having a library within the organisation which is doing similar work would be beneficial in helping us understand the needs here.
• NUnit.StaticExpect is originally based on NUnit.Framework. NUnit also housing the recommended replacement for the deprecated AssertionHelper class seems a sensible idea to my mind.
• Our vision talks about NUnit being 'unopinionated, support[ing] a number of different approaches to testing'. A particular motivation behind NUnit.StaticExpect was the syntax's similarity to JavaScript test framework syntax. Diversifying the syntax available within the organisation in this way seems like a great step.

Look forward to everyone's thoughts. 🙂

[ChrisMaddock]

@fluffynuts - please correct me on anything incorrect above - and add anything you wish to! It would also be worthwhile you having a look through vision.md - and see if there's anything you think may pose an issue to your plan for the library.

In terms of process, we should now wait to hear from the rest of the Core Team members. 🙂

[CharliePoole]

@ChrisMaddock I'm somewhat on the fence on this proposal, so you may take much of what I say as trying on the objections as a devil's advocate.

First of all, I should say that I do not believe we ever actually decided that the separate AssertionHelper project, if published, would be part of the NUnit organization. I was always a bit on the fence about that question as well. It could have ended up as my own separate project just as easily.

At any rate, StaticExcept is a great project and I think we should start supporting it in some way. We have really never figured out how to support external projects and I think we should. In NUnit V2, we had web pages that described "NUnit Extras" that were provided by other people. We gave a stamp of approval in that way and also pointed people to the projects. We have nothing like that now. I think we should do this for StaticExcept if we do not add it to the NUnit organization.

As far as whether we should add it, I'm not sure. WRT your three points...

We have a long term aim to support external constraint libraries for the framework. Having a library within the organisation which is doing similar work would be beneficial in helping us understand the needs here.

I can see that, but on the other hand having an external project we work with would help us as well, and perhaps more directly.

NUnit.StaticExpect is originally based on NUnit.Framework. NUnit also housing the recommended replacement for the deprecated AssertionHelper class seems a sensible idea to my mind.

It's definitely a lesser step and one we considered for AssertionHelper itself. I'd say this one is a tossup provided we can restrain ourselves from trying to control the project in some way. That would be my main worry.

Our vision talks about NUnit being 'unopinionated, support[ing] a number of different approaches to testing'. A particular motivation behind NUnit.StaticExpect was the syntax's similarity to JavaScript test framework syntax. Diversifying the syntax available within the organisation in this way seems like a great step.

Again, I don't see how this leads to a need to put the project into our organization.

The key question I ask myself about this is whether we can manage to host a relatively independent project within the NUnit organization. What degree of independence are we prepared to give the project lead? So far, we haven't shown that we know how to do that, although I think we are working on it. It could be that this project will serve as a test case as to how well we can handle such a situation and if @fluffynuts goes into it with full knowledge of the risks, I would support that. But I think we have a lot of definitional work to do around the role of a project lead in this organization.

Bottom line, I think we have work to do regarding how we interact with internal independent projects and external projects. I suppose we can choose which one to work on first.

[fluffynuts]

For what it's worth, I really only have two items on my list of desired outcomes:

1. Discoverability: people who are using AssertionHelper (or who would like to use the syntax) are able to easily find and successfully use NUnit.StaticExpect from deprecation notices, via Nuget.
2. Validation: potential users are re-assured in some way that NUnit.StaticExpect is endorsed (in some way, even if that means "this is a valid solution which we don't maintain") by the NUnit team, so that they can feel more secure in the quality of code and support.

However those are achieved is fine by me.

[rprouse]

@fluffynuts I definately see your library in the contrib spectrum. I would love to pull you into the organization and foster your project, but our experience with that in the past is that we don't have the people to keep all of the small projects ticking over and the experience isn't good. So, we as a team need to come up with a better way of supporting third party packages.

One way would be to clean up our downloads page and add a contrib section. I wouldn't want to be updating that too often, so probably just a link to the repo or to the NuGet package with a short description. Nothing versioned. First, I think we need to move our archived releases out to a separate page to make the download page more manageable. I will enter an issue for that.

One other thing to be aware of is that the NUnit.* prefix is reserved on NuGet. Because of packages like yours, we asked the NuGet team not to fully lock it down, but your package will never get the validation checkmark if you use that namespace. We were talking about adding an NUnit.Contrib.* sub-namespace that was open, but we haven't done that.

Another thing the team should discuss is use of the NUnit icon. I would prefer if non-official packages don't use the NUnit icon to prevent confusion. Should we provide an icon for contrib packages to use to distinguish them? Maybe the NUnit icon in a different color or with some sort of mark in a corner?

[jnm2]

Could we whitelist the contrib package maintainers to publish packages under NUnit.*? I can't see that hurting. I agree about the icon. A contrib icon is a great idea so people don't have to figure it out on their own. (Cake did a sweep a few months ago, asking contrib packages to switch to their contrib icon.)

[fluffynuts]

@jnm2 the whitelist idea, if possible, sounds like a good one.
On the matter of icon (and any other matters, tbh), I'm primarily interested in the experience for users of AssertionHelper and any potential users of the syntax who really want to go that route (I'm quite agnostic about it - use whatever works best in your team and project). So if a specific icon (or other branding mechanism) helps users to discover and/or trust the project, I'm all in.

The only strong opinion I have in this whole matter is focused on users who want this syntax and how to make consumption of this project optimal for them. I'm very easy on the implementation, as long as it focuses on that goal (:

[rprouse]

I asked about whitelisting. It isn't possible now, but may be in the future. The whole system is pretty new and there is more work to be done. For the icon, I would want it to be clearly NUnit derived, but also clearly not NUnit. Maybe just a blue version?

On Sat, Oct 21, 2017, 10:05 AM Davyd McColl ***@***.***> wrote: @jnm2 <https://github.com/jnm2> the whitelist idea, if possible, sounds like a good one. On the matter of icon (and any other matters, tbh), I'm primarily interested in the next experience for users of AsseetionHelper and why potential users of the syntax who really want to go that route (I'm quite agnostic about it - use whatever works best in your team and project). So if a specific icon (or other branding mechanism) helps users to discover and/or trust the project, I'm all in. The only strong opinion I have in this whole matter is focused on users who want this syntax and how to make consumption of this project optimal for them. I'm very easy on the implementation, as long as it focuses on that goal (: — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeJBNfJrqaz2_KCKt4lPNX3iQmbD0GOks5sufo8gaJpZM4P-PD0> .

-- Rob Prouse

[CharliePoole]

Thought experiment... let's imagine we figure out how to have good visibility of contrib projects, with icon, nuget support, etc. and implement it. We should have that ability in any case.

In that case, what would be the reasons to include a project in the NUnit organization? My thoughts...

• If the project were going to die without our support, i.e. maintainer moving on and nobody else to take over.

• We want the Core Team to manage the project (and contributor agrees)

• We want to share the project workload and/or the contributor wants to share our workload. (However, this can be done as separate projects as well)

• We want to bundle the project with other NUnit projects. Possibly also relevant if we just want to coordinate releases in some way.

• We want to "adopt" the project as the best way to extend NUnit in a certain way. I'm not sure we would want to do this, but it might apply, for example, with BDD extensions. There could be many that we link to but one that we considered "ours."

Of course, the benefits have to be weighed against the effort involved. If we do incorporate a new project like StaticExpect we need a way to avoid adding to our workload of handling notices, issues, etc. That's particularly problematic for the organization owners, but there is probably a way to shut off notices for a given project.

That said, it seems to me that somebody on the core team has to pay some level of attention to any project we incorporate. That's what users would expect.

[rprouse]

Just a quick addition, you can shut off notices to some repositories in the organization. I have done so for a few unless I am @ mentioned.

[ChrisMaddock]

I want to draw some conclusions here.

1. I think there's the general feeling that there's little net gain to bringing NUnit.StaticExpect inside the organisation, and the core team is currently quite time limited to support that process.
2. NUnit.StaticExpect would be a great fit for a 'contrib' setup. However, that's not something we have set up yet - and not something I think any of us currently have the time to prioritise. I think we agree that, when we get eventually round to this, NUnit.StaticExpect would be first in line.
3. @fluffynuts's main concern is that NUnit.StaticExpect is discoverable, and has some 'validation' from the NUnit team. I think directing users that way in the docs/obsoletion notes, as discussed here is a good step in that direction, until we have a more official 'whitelisting' system in place.

I think it's best to close this issue with that, as it sounds to me like this is the best solution we can reach right now, with the limited time we all have. If anyone disagrees, shout and we can reopen. 🙂