Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests with a period (.) in their name are displayed incorrectly #9609

Closed
TysonMN opened this issue Jul 1, 2020 · 6 comments
Closed

Tests with a period (.) in their name are displayed incorrectly #9609

TysonMN opened this issue Jul 1, 2020 · 6 comments

Comments

@TysonMN
Copy link

TysonMN commented Jul 1, 2020

Tests with a period (.) in their name are displayed incorrectly.

Steps to reproduce

This solution ZIP contains the following test code.

module TestNamespace.TestModule
open Xunit
[<Fact>]
let ``Test without a period in its name`` () = ()
[<Fact>]
let ``Test with a . in its name`` () = ()

Actual behavior
These tests are displayed in the test explorer like this.
2020-07-01_11-46-53_166_devenv

It is as though the namespace, module, and test names were concatenated together and then parsed back out like this.

NamespaceName.ModuleName.Test with a . in its name
        namespace       |   module   |    test

Expected behavior
I expected the parsing to be like this...

NamespaceName.ModuleName.Test with a . in its name
  namespace  |  module  |           test

...so that the tree in the solution explorer would look like this.

  • ProjectName (2)
    • NamespaceName (2)
      • ModuleName (2)
        • Test without a period in its name
        • Test with a . in its name

Known workarounds

Don't include . in a test name?

I encountered this problem while investing this issue in which a certain test passes for some target frameworks when the code under test is built with some .NET Core SDKs but fails with other choices. At one point, I considered putting in the test name how its result depends on the versions of the .NET Core SDK. In the end, I decide not to include that information in the test name.

Related information

  • Operating system: WIndows 10 Enterprise Version 10.0.18362 Build 18362
  • .NET Runtime kind: The MWE targets .NET Core 3.1 and the most recent version of the SDK that I have is 3.1.301 (x64)
  • Editing Tools: Visual Studio Enterprise 2019 Version 16.6.3
@abelbraaksma
Copy link
Contributor

abelbraaksma commented Jul 1, 2020

As a workaround, you may try using one of the other period look-alike characters.

I've had similar issues with other test clients when using a colon in the name. While the CLI allows any character in a member name, test clients apparently take the fully qualified name and operate on that, as opposed to split the namespace, class and member parts. This seems to be to be a bug with the test client not F#.

@CaptnCodr
Copy link
Contributor

This bug is very annoying when you have tests with float you describe e.g.: 9.1 should not be 10.5 or something like this.

@cartermp
Copy link
Contributor

cartermp commented Jul 3, 2020

This is ultimately the VS test runner UI separating things out by namespace and sub-namespace. @peterwald any thoughts here? The scenario (which you can also see in the tests in this codebase) is double backtick-quoted identifiers for module and test method names:

[<TestFixture>]
module ``Some tests for 1.0 and 2.0`` =

    [<Test>]
    let ``1.0 + 2.0 is 3.0``() = ...

@peterwald
Copy link
Member

@cartermp Yes, the VS Test Explorer currently parses the FQN using heuristics to try to determine the hierarchy, which in this case produces a bad result. The best workaround currently is to avoid using a period in the test name. We do have plans to remove our reliance on the FQN parsing and provide more hooks for the test adapters to supply the Namespace and Class hierarchy items directly (which would eliminate this issue).

/cc @shyamnamboodiripad

@cartermp
Copy link
Contributor

cartermp commented Jul 6, 2020

Thanks for the info! Is there a bug in AzDo this could be attached to?

@peterwald
Copy link
Member

@cartermp This could be attached to 560932 and/or 571675.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants