Closed mbuhot closed 5 years ago
I do not know Expecto, so maybe I will ask stupid question. Anyway, I will be happy to hear an explanation:
To run a single feature, change
[<Tests>]
to[<FTests>]
and it will focus on that feature.
versus
In order to allow the features to be run individually, I've declared a module-level variable with a
[<Tests>]
attribute for each feature file.
Can you please explain?
Sorry for the poor description, I'll try to clarify.
Expecto tests are run as console application, so it doesn't have a nice IDE experience for running individual tests like NUnit/xUnit.
Instead you typically change an attribute from Test
to FTest
(short for Focussed Test) and then run the console app.
I originally tried to discover all the TickSpec
feature files automatically like this:
[<Tests>]
let featureTests =
assembly.GetManifestResourceNames()
|> Array.filter (fun resource -> resource.EndsWith(".feature"))
|> Seq.map (featureFromEmbeddedResource >> testListFromFeature)
|> Seq.toList
|> testList (assembly.GetName().Name)
However, grouping all the tests like that makes it difficult to run a single feature.
So instead I've made it a little more explicit by listing each of the feature files separately:
[<Tests>]
let stockTests = featureTest "Stock.feature"
[<Tests>]
let additionTests = featureTest "Addition.feature"
Allowing the attribute on a single feature to be changed from Test
to FTest
if desired:
// Only run the stock tests
[<FTests>]
let stockTests = featureTest "Stock.feature"
// This will be ignored
[<Tests>]
let additionTests = featureTest "Addition.feature"
Does it perhaps make sense to reorient this example to reference the xunit or nunit test suite but simply show the incremental work to allow you to use Expecto ?
While this introduces some noise, the chances are that Expecto folks will understand xUnit enough to be able to get the point, and folks new to Expecto will see that there's not much extra work required to expose tests to Expecto ?
(I'm also wondering whether some of the helper code shared across test frameworks needs to go into a common file? It's getting quite a few copies from glancing?)
I don't have strong feelings on this; I'm only providing this as food for thought (but my copy paste alert is going off ;) )
It would be great to have a set of feature files and some shared domain logic in a common project.
If that is the future direction then perhaps I can strip this PR back to a minimal example then refactor in a subsequent PR?
I personally have no specific plans around this; my main interest is trying to have a) the repo b) the solution when loaded by a newcomer clearly show the various technical aspects (runner support, various test styles, tricks like DI) along with conveying how Gherkin works in general at a glance.
Being able to do that involves some mix of
I'll leave it to your judgement whether to do this as a preparatory refactoring or leave it to be done when the time is right (I have not looked recently - perhaps some frameworks need to be pruned and/or some examples de-emphasized by putting into folders etc. to optimize the newcomer experience?)
@mchaloupka I'd prefer to merge this PR as it is and follow up with another PR to see what it looks like to reduce some of the duplication.
Merged, thanks.
Resolves #30
In this PR I've ported the xUnit
ByFramework
example to Expecto.In order to allow the features to be run individually, I've declared a module-level variable with a
[<Tests>]
attribute for each feature file.To run a single feature, change
[<Tests>]
to[<FTests>]
and it will focus on that feature.The
YoloDev.Expecto.TestSdk
dependency was required to allow running an expecto test program with thebotnet test
cli from the build script.