docs site updates

src/FlUnit.Documentation/FlUnit.Documentation.csproj

@@ -7,9 +7,9 @@
   </PropertyGroup>
 
   <ItemGroup>
-    <PackageReference Include="Markdig" Version="0.31.0" />
-	  <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="8.0.0" />
-	  <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="8.0.0" PrivateAssets="all" />
+    <PackageReference Include="Markdig" Version="0.36.2" />
+	  <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="8.0.3" />
+	  <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="8.0.3" PrivateAssets="all" />
 	  <PackageReference Include="Microsoft.Web.LibraryManager.Build" Version="2.1.175" />
   </ItemGroup>
 

src/FlUnit.Documentation/wwwroot/md/roadmap.md

@@ -2,7 +2,28 @@
 
 Proper issue tracking would be overkill, so just a bullet list to organise my thoughts:
 
-- v1.3 is likely to include:
+- Next up:
+  - Support for async tests:
+	- First and foremost, need to allow async then clauses - assertion delegates should be allowed to return Tasks,
+	  framework should await them appropriately.
+    - Currently, there's nothing stopping "Given" and "When" clauses from returning tasks - but it might be nice to
+	  allow the framework to await them so that the following logic doesn't *have* to do so itself (thus potentially
+	  simplifying test logic). `WhenAwait`? `GivenAwait`/`GivenEachOfAwait`)?
+
+- On the to-do list for soon-ish:
+  - Fix VSTest adapter so that the test assembly is loaded in a reflection-only context when discovering tests.
+  - Allow for instantiable test fixtures rather than just static test properties, with an abstract
+    factory to allow for extensions that hook into various DI frameworks (and some mechanism for initialisation
+	of the DI container).
+  - Basic test tidy-up support. Open questions here about if/when we should consider objects (prerequisites,
+    test function return values) to be "owned" by the test, and thus its responsibility to dispose of. What
+	is the ideal default behaviour, and by what mechanisms should we support deviation from that.
+  - Test attachment support
+
+- On the to-do list for later:
+  - VSTest platform adapter internal improvements
+    - Improvement of stack traces on test failure (eliminate FlUnit stack frames completely)
+    - Get rid of some aspects of the core execution logic that are too influenced by VSTest
   - Configurability:
     - Test case labelling is still annoying after the minor improvement made in v1.2. Better support for custom test case labelling, and perhaps further improved default labelling. Currently mulling over some options, including:
 	  - ~~in default labelling, spot and eliminate *all* type names (even ones contained *within* prereq tostrings..).
@@ -27,30 +48,15 @@ Proper issue tracking would be overkill, so just a bullet list to organise my th
 	  Con: seems most useful for particular values for particular test cases, but config really for stuff across a whole test suite.
 	  when its for a particular test, `LabelledAs` feels more powerful?
     - Expand on parallel partitioning control by allowing for by class name and namespace - whether thats treated as a special case or if we hook this into trait system is TBD.
-- On the to-do list for later:
-  - Configurability:
     - Of strategy for duration records (which currently makes a "sensible" decision which may not be appropriate in all situations). Look at achieving greater accuracy in durations in the vstest adapter. Now that I realise you can record duration separately to start and end time. I could pause the the duration timing while doing framework-y things..
 	- Take a look at configurability of test execution strategy in general (should different cases be different "Tests" and so on).
 *NTS: What this'd look like, probably: TestDiscovery to get Test and `Arrange` it.
 Look at resulting (potentially overridden) test config for appropriate granularity setting.
 Then return testmetadata that now optionally include case/assertion index.
 This index info would need to be included in VSTest case serialization (see VSTest.TestDiscoverer and TestContainer).
 TestRun would need to then act accordingly (TBD whether it could/should execute once but split the results, or rerun) based on the metadata.
-Of course a gotcha here is that GivenEach.. doesn't have to return the same number of cases each time (which I maintain is good behaviour - allows for storage of cases in external media). Would need to handle that gracefully.*
-  - Basic test tidy-up support. Open questions here about if/when we should consider objects (prerequisites, test function return values) to be "owned" by the test, and thus its responsibility to dispose of. What is the ideal default behaviour, and by what mechanisms should we support deviation from that.
-  - Support for async tests:
-	- First and foremost, need to allow async then clauses - assertion delegates should be allowed to return Tasks,
-	  framework should await them appropriately.
-    - Currently, there's nothing stopping "Given" and "When" clauses from returning tasks - but it might be nice to
-	  allow the framework to await them so that the following logic doesn't *have* to do so itself (thus potentially
-	  simplifying test logic). `WhenAwait`? `GivenAwait`/`GivenAwaitEachOf` (careful with that second one..)?
-  - Should at some point allow for instantiable test fixtures rather than just static test properties, with an abstract
-    factory to allow for extensions that hook into various DI frameworks.
-  - Test attachment support
-  - VSTest platform adapter internal improvements
-    - Improvement of stack traces on test failure (eliminate FlUnit stack frames completely)
-    - Get rid of some aspects of the core execution logic that are too influenced by VSTest
-
+Of course a gotcha here is that GivenEach.. doesn't have to return the same number of cases each time (which I maintain is good behaviour - allows for storage of cases in external media). Would need to handle that gracefully.
+Problems here: simply can't if target bitness differs, and presumably need to isolate so can unload/reload - AppDomain usage might suffice?*
 Not going to do, at least in the near future:
 - QoL: Perhaps `Then/AndOfReturnValue(rv => rv.ShouldBe..)` and `Then/AndOfGiven1(g => g.Prop.ShouldBe..)` for succinctness? No - Lambda discards work pretty well (to my eyes at least), and `OfGiven1`, `OfGiven2` is better dealt with via complex prereq objects
 - QoL: dependent assertions - some assertions only make sense if a prior assertion has succeeded (easy for method-based test frameworks, but not for us..). Such assertions should probably give an inconclusive result? Assertions that return a value (assert a value is of a particular type, cast and return it) also a possibility - though thats probably inviting unacceptable complexity. A basic version of this could be useful though - perhaps an `AndAlso` (echoing C# operator name) - which will make all following assertions inconclusive if any prior assertion failed? No - this is best left to assertion frameworks (e.g. FluentAssertions `Which`)

src/FlUnit.Documentation/wwwroot/md/user-guide/getting-started.md

@@ -119,7 +119,7 @@ In particular, the enforced structure for tests (notably, no interlacing of acti
 - **It's conventionless and discoverable.**
 The fluent builders enable you to discover functionality by your IDE showing available builder methods. No more having to look up what attributes you need to do parameterised tests, how to inject context into a test class constructor, and what static types to use to do test output.
 - **A richer model for tests than that found in many other test frameworks** (without requiring the verbose code required by frameworks such as MSpec) makes a few things possible, some of which are demonstrated in the "getting started" guidance, above.
-  - Parameterised tests are easy without requiring awkward attribute-based parameter retrieval. Note that this is essentially because the prerequisites are passed to the "When" delegate - meaning that *all* tests are parameterised.
+  - **Parameterised tests** are easy without requiring awkward attribute-based parameter retrieval. Note that this is essentially because the prerequisites are passed to the "When" delegate - meaning that *all* tests are parameterised.
   - The "arrange" clauses of a test don't have to be counted as part of the test proper, providing an easy way to distinguish inconclusive tests (because their arrangements failed) from failed ones - providing some assistance to the isolation of issues.
   - Specifying each assertion separately means we can record them as a separate results of the test - providing an easy way to achieve the best practice of a single assertion per test result without requiring complex code factoring when a single action should have multiple consequences. Further, we can use language & framework features to name said results automatically (CallerExpressionArgument for .NET 6+, LINQ expressions for earlier versions). This makes it easy to write tests that show what is being asserted at a glance, without requiring test failure (or unhelpfully long test names). This in turn makes your tests more discoverable, and ultimately plays a small part in making your production code easier to maintain.