FYI @blairconrad - A little follow-up on what I'm generally trying to achieve:
Following advice from a Greg Young video (circa 2011/12) on doing DDD tests with Event Sourcing, I'm looking at leveraging xbehave with patterns of
.ToString() on Commands/Events to write lean but expressive tests that output nicely to HTML (see image below).
Hey there, I'm new to xbehave and I wanted to ask a style question. The docs say ", it should never be necessary to write code outside of a step. If you ever find a need to do so, please let us know"; I've found a reason and I wanted to know what you thought.
I've got a massive amount of data-oriented test-cases. While most of the test cases require most steps and assertions to run, some should fail. This logically led to using a if statement to test these two different branches, and violated the no writing code rule.
The tests run and work how I'd like but from a style perspective, are there any problems with this?
@adamralph Thanks for the response. I thought about doing as you suggested but there are multiple attributes to be tested - the date example i showed is just the first case... then there's lat, lng, etc... Though that means I should probably think about factoring this into smaller chunks anyway. I think this feature xbehave/xbehave.net#17 would make it easier to factor these into smaller specifications.
However, I have been using the branching, like above, and from a technical standpoint there doesn't seem to be any problems...
test.DateParseable == false, why not make
test.ExpectedDateTime = null? Then you can use
Assert.Equal()for all cases.
test.DateParseableproperty may become redundant
xBehaveMarkdownReportis designed to consume the output of the xunit console runner only. Someone else was trying this for the "trx" output, and raised an issue here: appccelerate/xBehaveMarkdownReport#3
xBehaveMarkdownReportshould work just fine
dotnet testwould be enough to be honest
describe AuthorizationProcessor when processing given authorization request is null throws ArgumentNullException (6ms) given acquirers is null throws ArgumentNullException (0ms) given no acquirers are provided throws ArgumentException (0ms) given one acquirer is provided and the acquirer declines the payment is not approved (2ms) and the acquirer throws is not approved (0ms) and the acquirer approves the payment is approved (0ms) given multiple acquirers are provided and the first acquirer approves the payment is does not cascade (0ms) and the first acquirer declines the payment and the response code can not be cascaded is does not cascade (0ms) and the response code can be cascaded cascades to the next acquirer (0ms)