@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)