Expect.equal stops discovery

[jackfoxy]

Expect.equal stops further discovery of tests.

    [<Tests>]
    let equality =
        testList "equality" [
            testCase "equality 1" <| fun () ->
                Expect.equal 42 42 ""
            ]

Place some other tests before and after this in a module. You will see the tests before discovered, the others not.

[8/22/2017 4:13:11 PM Informational] ------ Discover test started ------
[8/22/2017 4:13:11 PM Error] System.ArgumentException: An item with the same key has already been added.
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at Mono.Cecil.Cil.MethodDebugInformation.GetSequencePointMapping()
   at SourceLocation.SourceLocationFinder.getFirstOrDefaultSequencePoint(MethodDefinition m)
   at <StartupCode$Expecto-VisualStudio-TestAdapter>.$SourceLocation.candidateSequencePoints@71-2.Invoke(MethodDefinition m)
   at Microsoft.FSharp.Collections.IEnumerator.map@114.DoMoveNext(b& )
   at Microsoft.FSharp.Collections.IEnumerator.MapEnumerator`1.System-Collections-IEnumerator-MoveNext()
   at <StartupCode$Expecto-VisualStudio-TestAdapter>.$SourceLocation.clo@41.GenerateNext(IEnumerable`1& next)
   at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase`1.MoveNextImpl()
   at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase`1.System-Collections-IEnumerator-MoveNext()
   at Microsoft.FSharp.Collections.IEnumerator.map@114.DoMoveNext(b& )
   at Microsoft.FSharp.Collections.IEnumerator.MapEnumerator`1.System-Collections-IEnumerator-MoveNext()
   at Microsoft.FSharp.Core.CompilerServices.RuntimeHelpers.takeOuter@683[T,TResult](ConcatEnumerator`2 x, Unit unitVar0)
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.OrderedEnumerable`1.<GetEnumerator>d__1.MoveNext()
   at Microsoft.FSharp.Collections.IEnumerator.map@114.DoMoveNext(b& )
   at Microsoft.FSharp.Collections.IEnumerator.MapEnumerator`1.System-Collections-IEnumerator-MoveNext()
   at System.Linq.Enumerable.<TakeIterator>d__24`1.MoveNext()
   at Microsoft.FSharp.Collections.SeqModule.TryFind[T](FSharpFunc`2 predicate, IEnumerable`1 source)
   at Discovery.Discoverer.Microsoft-VisualStudio-TestPlatform-ObjectModel-Adapter-ITestDiscoverer-DiscoverTests(IEnumerable`1 sources, IDiscoveryContext discoveryContext, IMessageLogger logger, ITestCaseDiscoverySink discoverySink)
[8/22/2017 4:13:11 PM Informational] ========== Discover test finished: 48 found (0:00:00.4400538) ==========

[alex-bogomaz]

latest upgrade of "Mono.Cecil" to "0.10-beta7" should fix this issue

[jackfoxy]

I can confirm, this fixed the problem in my case. Tested on VS2017 15.4.3.

I also discovered that VS very aggressively caches AppData\Local\Temp\VisualStudioTestExplorerExtensions\Expecto.VisualStudio.TestAdapter.5.0.0.2

Something to watch out for when testing in this case, since TestAdapter.5.0.0.2 did not look like it changed. I just copied the Mon.Cecil files. It's not enough to delete the cached folder, you need to restart VS as well.

Hope to see a new release of TestAdapter soon.

Out of curiousity, why are these bug fixes incrementing the build number (according to semantic versioning) and not the patch number? I would suggest incrementing the patch number, as I have found these fixes crucial to getting the adapter to work for users. Build number incrementing tends to have the "look" of being less important.

From my perspective this can be closed after a new release. Thanks, as always, for the contribution.

[MNie]

@jackfoxy my mistake it should increment the bug section of an adapter version instead of build section. I updated nuspec and release notes on github.

[MNie]

New version released, I'm closing it.