All Versions
14
Latest Version
Avg Release Cycle
86 days
Latest Release
1627 days ago

Changelog History
Page 1

  • v3.0.0-beta.1

    November 14, 2020

  • v3.0.0-alpha.3

    September 19, 2020

  • v2.2.2 Changes

    December 12, 2020

    🛠 Fixes #246 "Enable RollForward = Major to run on later .NET Core versions": For the 2.x line, the Fixie.Console installed by DotNetCliToolReference respects major version roll-forward, so that consumers no longer have to install and old SDK just for invoking tests compiled with more recent SDKs.

  • v2.2.1 Changes

    April 26, 2020

    🚀 The previous release supported .NET Core 3 test projects for most use cases, but as a happy coincidence. No action had to be taken in Fixie's implementation, as the existing support for .NET Core 2 carried forward naturally.

    👍 Fixie 2.2.1 includes official support for such test projects. However, because netcoreapp3.0 has already reached End-of-Life, netcoreapp3.0 is not supported. As a Long-Term-Support release, netcoreapp3.1+ is supported. If you need to target netcoreapp3.0, we recommend sticking with Fixie 2.2.0 until you can upgrade to a target framework supported by Microsoft.

    ✨ Enhancements for .NET Core Test Projects:

    • 👌 Improved readability of test failure stack traces for netcoreapp2.1+.
    • 🐎 When consumers target netcoreapp3.1+, internal messaging serialization uses System.Text.Json.JsonSerializer instead of the deprecated DataContractJsonSerializer, for its simpler API and improved performance.
    • 🐎 Update VS Test Platform dependencies to take advantage of their performance improvements.
    • 🛠 Fixed the ability to run tests under the debugger in Visual Studio's Test Explorer for netcoreapp3.1+ test projects.

    ✨ Enhancements when running on Azure DevOps:

    AzureDevOps

    • ✅ When a test assembly completes, the test run as a whole is marked as completed. Doing so lights up several elements in the Azure DevOps "Tests" screen: assembly-level success/failure icons, assembly-level durations, and high-level statistics.
    • ✅ When posting skipped test results to Azure DevOps, use the 'outcome' value 'Warning'. This allows the Azure DevOps UI to properly categorize the result, to display a warning icon by the result, and to pass through the skip reason as a visible message. Don't skip tests.
    • 🏗 #211: Improved logging and error handling around Azure DevOps API failures, allowing test runs to complete with full details in the build log and an accurate exit code even when the Azure DevOps API fails completely.

    Other Enhancements:

    • ✅ Because AppVeyor relies on test case name + the assembly FileName to distinguish unique results, include the target framework in that FileName. This way, test results are correctly distinguished from each other during test runs of multitargeted test assemblies.
    • 📦 Modernize deprecated elements in NuGet packages.

  • v2.2.0 Changes

    October 05, 2019

    📚 When running under Azure DevOps, if you have configured your Pipeline to allow access to the Azure DevOps test reporting API, Fixie will report each test result so that they will appear on the build's "Tests" screen. If you forget that configuration, the console output will provide guidance based on the Azure DevOps documentation (https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables#systemaccesstoken)

    image

  • v2.1.1 Changes

    July 24, 2019

    ✅ When running tests in Visual Studio under Test Explorer:

    • 👌 Improved error reporting, both in the Output pane and in the tree of test results, to help with troubleshooting.
    • 👌 Improved performance when selecting a large number of individual tests to run in Test Explorer. Previously, we performed an excessive amount of reflection and redundant evaluation of which test classes and test methods need to be executed.
    • ↔ Integrate with Test Explorer's test progress icons, so that the user can identify long-running tests.
    • ✅ Graceful handling of catastrophic failures such as tests which perform Environment.Exit(...) or which throw StackOverflowException. Naturally such catastrophic errors force the test run to end early, and that is out of our control, but now we accurately report what happened in both the Test Explorer tree and in the 'Tests' Output pane.

  • v2.1.0

    July 24, 2019

  • v2.0.4 Changes

    April 04, 2019

    VS 15.8

    🚀 Release 2.0.2 attempted to integrate with breaking changes in Visual Studio 15.8. It failed, however, to properly deal with the following combination:

    • ✅ Test assembly targets Full .NET Framework
    • 🐎 Enabling the new option Tools \ Options \ Tests \ "For improved performance, only use test adapters in test assembly folder..."

    ✅ In this scenario, Test Explorer would fail to locate a dependency (Mono.Cecil) causing those tests to disappear from Test Explorer.

    🚀 With this release, Tests Explorer is expected to behave well regardless of the new Tools \ Options \ Tests setting.

    ✅ Handling Stale Test Discovery Information

    ✅ Because test runners like Test Explorer can request specific tests to run using stale discovery data (such as selecting a test to run which has been renamed but not yet recompiled), we now take care to only execute requested tests which in fact exist.

    ✅ Test Exception Handling

    ✅ We simplified the way that test exceptions are captured and propagated while preserving original stack traces.

    ✅ For async tests, this means favoring task.GetAwaiter().GetResult() over task.Wait(), simplifying our implementation and providing a more readable stack trace.

    We leverage ExceptionDispatchInfo.Throw(), though we take care to omit the portion of the resulting stack trace that verbosely describes Fixie's own calling of that method.

  • v2.0.3 Changes

    December 04, 2018

    🐛 Bugs Fixed

    • When formatting output under TeamCity, ensure all non-ASCII characters are properly escaped.
    • ✅ When asynchronous F# test cases return the F#-specific Async<'T> type, ensure that execution has completed before determining the case's result.
    • ✅ Ensure that execution of any asynchronous test case completes before determining the case's result, whether or not the async keyword is present, even when the Task object is returned from a method declared with object as the return type.
    • ✅ Asynchronous test cases which return the null task always pass, as there is no more work to perform.
    • ✅ Asynchronous test cases fail with a clear explanation, instead of blocking indefinitely, when the Task returned was never started.

    Huge thanks to @petejohanson!

  • v2.0.2 Changes

    September 03, 2018

    ✅ Visual Studio 15.8 included an intentional breaking change to the way Test Explorer discovers third party "test adapters" like Fixie.VisualStudio.TestAdapter.dll.

    Historically, Test Explorer would search for .NET Core adapters only in the build output folder, while it would search for .NET Framework adapters in both the build output folder and the referenced NuGet packages. When Fixie 2.0.0 was released, we took advantage of the NuGet package search in order to avoid having to wastefully copy the adapter DLL to the build outpuf folder for .NET Framework builds.

    🚀 Visual Studio 15.8 includes a breaking change in the interest of performance. The search no longer considers NuGet package contents when discovering test adapters. This release fixes Test Explorer integration by including the same DLL copy for .NET Framework projects as we've been doing for .NET Core projects.

    ✅ As a side effect, dotnet test integration is likewise improved, though we still recommend using dotnet fixie instead.