Re: Tests more complex than the solution they drive
|
For me, it's great that you have 2 independently deployable pieces. Though I would ensure I also had independently runnable tests. With the exception of having contract tests to test your expectations of the backend interactions. This will have benefits of being easier to reason about (at least once you start to feel comfortable with the concept); faster test suites; less brittle maintenance.
In a similar setup to what you have, I've had?end-to-end system tests in the past, but I literally only had 1 or 2 validating the most important use case still worked after each deploy (of either side).
Good luck!
On Mon, Sep 7, 2020 at 7:17 AM paulnmackintosh < pnm@...> wrote: The in solution 'framework' that has evolved for these tests does have a bit of a system test feel to it, although it is being leant on to test drive new classes with new behaviours.
Here's an example in pseudo code in case it helps:
[Fact]
public async Task ExampleFact()
{
? await TestScenario
? ? .Given(builder => builder
? ? ? .UserCreatesEntityA("Entity A")
? ? ? .UserCreatesEntityB("Entity B",?new[]?{?new DetailForB { Name = "Detail B"},?})
? ? ? .SystemCreatesEntityC()
? ? ? .SystemActsOnAAndBAndC()
? ? .When(builder =>
? ? ? builder.ExerciseNewUnitUnderTest())
? ? .Then(results =>
? ? {
? ? ? // use results to assert
? ? });
}
|
