Made a quick change to the RouteAttribute to support arbitrary HTTP verbs. Added PATCH for both MVC and WebApi.

I'm not sure how you go about testing these attributes, but I tried to follow the convention about defining the common "API".

I can probably add HEAD and OPTIONS attributes as well.

Fixes package-lint error:

eglot-fsharp.el:6:52 (package-lint-warning) Version dependency for fsharp-mode appears too high: try 1.9.15

Fixes package-lint error:

eglot-fsharp.el:6:52 (package-lint-warning) Version dependency for fsharp-mode appears too high: try 1.9.15

thanks for stepping in :+1:

I relaxed the Emacs version dependency to 26.3 (minimum required version for eglot).

The remaining package-lint error eglot-fsharp.el:157:9: error: You should depend on (emacs "27.1") if you need jsonrpc-error seems to be a false positive. The required jsonrpc library is installed as transitive dependency when using Emacs 26.3.

Dependency-Tree of 26.3:

fsharp-mode 1.9.15
    s 1.3.1    [1.12.0 installed]
    eglot (any)    [1.7 installed]
        jsonrpc 1.0.14

This patch fixed most issues from https://github.com/melpa/melpa/pull/7336.

This patch fixed most issue from https://github.com/melpa/melpa/pull/7336.

Emacs 25 ships with a sequence library named seq.el. This renders dash.el completely obsolete.

Emacs 25 ships with a sequence library named seq.el. This renders dash.el completely obsolete.

26.3 failure doesn't seem to be related to this change: Need to investigate

eglot upstream: Flex completion style is not available on Emacs < 27

Refs #253

eglot-fsharp depends on fsharp-mode

26.3 failure doesn't seem to be related to this change: Need to investigate :fearful:

Refs #253

eglot-fsharp depends on fsharp-mode

With pleasure!

Done.

Fix a few stylecop naming convention warnings while I'm in the file

Thanks @rprouse I've rebased the branch

Hello! I have an abstract test class, that contains test methods. Then some classes that derive from this abstract class. The TestExplorer GUI recognizes the class deriving from abstract class structure, but the testNames are only with abstract class name. I would need to show NUNIT the fullName of test method, including the class name and abstract class name.

• the TestName pattern {M}{a} gives me: NUnitTestProject1.Tests.Test1("hello")

• the FullName would be: NUnitTestProject1.NUnitTestProject1.Tests+TestImplement1.NUnitTestProject1.Tests.NUnitTestProject1.Tests.Test1("hello")

I am missing the "TestImplementation1" class name in TestName. It seems like this is not possible, as answered in stack overflow question.
I tried different nunit patterns, also runsettings file with <DisplayName>FullNameSep</DisplayName>. As Chris on StackOverflow pointed out, TypeHelper.GetDisplayName is not exposed through any pattern. link

TestExplorer GUI, including the TestImplement1 information in hierarchical structure, but not in TestName:

simplyfied test class:

namespace NUnitTestProject1
{
    public abstract class Tests
    {
        public class TestImplement1 : Tests
        {
        }

        public class TestImplement2 : Tests
        {
        }

        [Test]
        [TestCase("hello", TestName = "{M}{a}")]
        public void Test1(string param1)
        {
            Assert.Pass();
        }
    }
}

I have to create an object before all tests start execute and then after all test execute the data on this object will be inserted to a database. The test fixtures are expecting parallel. What is the best approach in NUnit to get the suite level control?

Is there a way I can use reflection to get the Suite level access?

I'm going to close this as a question. Feel free to post with more info.

The most recent release of dotnet CLI does not work with our cake build script unless the correct SDK is installed. Several users have run into problems building because of this. We should check that the correct version of the SDK is installed, not just that the CLI is installed.

My email response to one is below,

The .NET Core code was developed for the older .NET Core tooling. The initial failure is restoring NuGet packages.

You are having the issue because you do not have .NET Core 1.0.0-preview2-003131 installed (see global.json).

At the command line, if you type dotnet --version in the NUnit directory, you should see 1.0.0-preview2-003131 because .NET Core tries to respect the global.json. You will likely see just 1.0.0.

For example, when I type dotnet --info another directory, I see,

D:\src
λ dotnet --info
.NET Command Line Tools (1.0.0)

Product Information:
 Version:            1.0.0
 Commit SHA-1 hash:  e53429feb4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15031
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0

But when I type it in the NUnit source directory, I see

D:\src\NUnit\nunit [master ≡]
λ dotnet --info
.NET Command Line Tools (1.0.0-preview2-003131)

Product Information:
 Version:            1.0.0-preview2-003131
 Commit SHA-1 hash:  635cf40e58

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15031
 OS Platform: Windows
 RID:         win10-x64

I believe that you can download that version of .NET Core from https://github.com/dotnet/core/blob/master/release-notes/download-archives/1.0.1-preview2-download.md

I'm not sure we need to do anything with this anymore. I think build errors are clearer and I haven't seen issues recently, so I'm going to close this. We can reopen with newer information if necessary.

It is easy to track the progress through the tests (start/finish) by using the methods of the ITestListener interface.

However, there seems to be no mechanism to allow a single test to provide real-time progress (e.g. percent completed) information to something like an ITestListener.

It would seem useful to add a property to the TestContext such as PercentComplete that a test could set while it was running. Each call to the setter would in turn call a TestProgress method on the ITestListener interface, with an ITestProgress as the argument (which would contain appropriate information about the test - perhaps just ITest + Progress).

This would seem useful for the GUI, and for other runners as well.

There has been no discussion on this since 2016, so I am going to close. It can be reopened if someone wants to move it forward.

Is there any way to easily write a global SetUp or TearDown method?

This would be like a SeUp or TearDown that would be run once for each TestFixture in the test suite.

If not, it seems like it would be very useful to have one.