2.0.0

Updated to latest version of abstractions assembly, so that it can work with the latest version of the VSTest adapter.

Dropped the .NET Standard target. Leveraging CallerArgumentExpression for automatic result naming is important for FlUnit - the LINQ expression approach for pre-.NET 6 doesn't really cut it as an alternative, and having to manually name assertions undermines part of the benefit of FlUnit. Further, the VSTest adapter simply doesn't work for full framework when your test project needs binding redirects - I'd need to do work that I'm not particularly interested in doing at this point to make this happen. I suspect that literally no-one will care - but on the off-chance that someone does, feel free to reach out. Just bear in mind that the first suggestion is likely to be that you pitch in if you want this re-added.

1.3.0

Added support for asynchronous test clauses.

• More or less all of the "Given", "When" and "Then" builder methods now have "..Async" versions, to which you provide an asynchronous delegate that the runner should await when running the test. The only exceptions are "ThenReturns" and "ThenThrows" - which don't allow async first assertions to be provided. This is simply because I figured that "ThenReturnsAsync" and "ThenThrowsAsync" are misleading, given that the "Async" here would refer to that first assertion, not the test action/function itself - which is not what the method name suggests, and thus could be confusing. You can of course just do ThenReturns().AndAsync(async () => ...) instead.
• Note that ITestContext now includes a CancellationToken property to communicate test cancellation to the test.
• NB: you must use version 1.3.0 (or rather, any version that references v3 of the abstractions package) of the VSTest adapter with this version of FlUnit - with earlier versions, test runs will abort with a "method not found" exception.
• Some degree of documentation of async test clauses should appear on the docs site at some point in the near future.

1.3.0-pre.1

Updated to use 3.0.0-pre.3 of the FlUnit.Abstractions package - adding in support for asynchronous test clauses. Version 1.3.0-pre.1 or later of the vstest adapter package must be used to run test projects that use this version of the package.

1.2.0

Minor improvements to default test result labelling. When outputting prereqs, items that don't override ToString (i.e. that just print out their type name) are now omitted. If that leaves nothing, we fall back on labelling as "test case #X".

1.1.2

Added Source Link

1.1.1

Damn it. Splitting everything up does have its downsides (but I maintain is the right call). Forgot to update dependencies to non pre-release versions.

1.1.0

Just adds test output and error message support via the ITestContext interface. See documentation for details.

1.1.0-pre.1

Initial pre-release of 1.1.0 - just adds test output support via the ITestContext interface. Pre-releasing mostly because I want to test it out in one of my other projects without faffing around with local builds..

1.0.0

NB: starting with this release, the only thing being published here is the FlUnit library. The other two (FlUnit.Abstractions and FlUnit.VS.TestAdapter) will be versioned and released separately now that we have reached v1.

Initial full release, with everything that reaching v1 (and adhering to the conventions of semantic versioning) entails. Notably, no breaking changes without a major version bump from this point onward. Changes from v0.15.0:

• The maximum prerequisite count has been increased from 3 to 5.
• Behind the scenes (this doesn't affect how you consume the library) - as per FlUnit.Abstractions v1.0, the Test implementations now implement IDisposable. The Dispose methods don't actually do anything yet, but in future may e.g. Dispose any IDisposable pre-requisites (assuming that we are happy that the Tests are considered to "own" the pre-requisites - needs thought - perhaps just configurability), or do custom test-specific teardown (arguable whether this would belong in Dispose, but...). The motivation here was in getting IDisposable added to the abstraction before hitting v1 - taking an (educated) gamble that this would be the approach taken going forwards..

0.15.0

Almost certainly the last pre-release before v1.0.0 (which almost certainly will have very few changes of its own).
Not a huge number of changes that a user would notice, but quite a bit under the covers:

• Added a (very brief) README to the packages
• Resolved most of the TODOs in the code:
  • Slightly improved stack traces in failure results & fixed an awkward throw new Exception occurrence when an implicit assertion fails (e.g. when using ThenThrows(ex => ...) but no exception is thrown).
  • Improved error message when an unexpected exception is thrown by a "When" clause
  • Localisation basics - most string hard-coding replaced by resources in a resource file. Should I ever be lucky enough that it becomes an issue, localisation should be relatively straightforward.
  • A bit more (probably unneeded, but easy and good practice) robustness in TestRun class in the VSTest adapter - in case of bad test runner behaviour
  • (Quickly looked into parallelisation of test discovery in VSTest adapter, but decided against it)
• Reviewed abstractions for flexibility & stability
  • Tweaked the ITraitProvider interface to make it a little more flexible
  • Changed Trait to ITrait. Might be overkill, but meh
  • Replaced Description property of ITestCase & IAssertion with IFormattable interface inheritance. Admittedly a bit of a calculated risk. IFormattable may be needlessly complex (not sure format strings for these will be useful*). However, a Description prop is almost certainly not going to be flexible enough for the amount of control I want to offer, so I think this is a slightly better bet for a stable abstraction. I did briefly consider if it should still have a Description prop, but it should be an IFormattable not a string, but iI think that would be overly complex compared to just inheriting IFormattable directly.

Worth noting a couple of things not included in the packages at all have also been done alongside this stuff:

• Added very basic performance benchmark (not yet invoked as part of validation build)
• A number documentation improvements

* then again, in a test where e.g. we're summing two numbers (so have two int-valued pre-reqs), being able to do something like specify a @x + @y format string (e.g. in .UsingConfiguration(c => c.ResultFormat = "{0} for test case {1:@x + @y}")) might be nice?