New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Unity) Attribute-based BDD-style tests #160
Conversation
Codecov Report
@@ Coverage Diff @@
## main #160 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 65 83 +18
Lines 1059 1438 +379
Branches 47 47
==========================================
+ Hits 1059 1438 +379
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
/// </remarks> | ||
/// <seealso cref="FeatureAttribute"/> | ||
/// <seealso cref="ScenarioAttribute"/> | ||
public abstract class BddTest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class is required because AFAIK, NUnit doesn't really support set ups, tear downs etc, if we make it execute a method in any other class. Some discussion here. Also, Unity makes this even more complicated with IEnumerableTestMethodCommand
being internal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks cool and exciting!
[Scenario("The game should be restartable easily after failure")] | ||
public IBddStep[] Restart() => new[] | ||
{ | ||
Given("the player has failed", this.FailTheGame()), | ||
When("the user presses the trigger key", this.MockTriggerInput()), | ||
Then("the game should be restarted", this.AssertTheGameHasBeenRestarted()) | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Vocabulary feedback:
When looking at this.MockTriggerInput()
(also in your opening post), it looks like you're mocking a trigger. But you aren't mocking anything, you're triggering something for real. Now perhaps the thing that's you're triggering is a mock.
I'd argue that in this example it could better be called this.SimulateTriggerKeyInput
.
Also; not sure if intended but you're using both "the player" and "the user" for the same actor here, which might not be necessary depending on the language of your team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that all makes sense!
I should probably review the sample tests as a whole from a consistency and vocabulary perspective.
Would look something like
...which results in the test runner looking like
...and the state output like:
Unity-only, because we don't depend on NUnit in vanilla C#.
TODO:
docs andchangelog (docs will be updated separately)