🫴 Proposal
After a test execution there can be different behavior when test succeed and when the test failed. This feature should add two new methods WhenSucceed and WhenFailed, which can be fluently chained after test method, like this:
tp.Test("Status code of response should indicate success." () => True(tp.Response.IsSuccessStatusCode))
.WhenSucceed(_ =>
{
Console.WriteLine("Status code indicates success, continue.");
})
.WhenFailed(response =>
{
Console.WriteLine($"Since this was critical request and failed with {response.StatusCode()}, testing has to end.");
tp.Exit(1, "Critical request failed.");
})
✨ Motivation
Sometimes, set of tests are dependent on each other and failure of previous can cause failures of following tests. To prevent such a behavior these two methods can logically separate the flows after test execution according its result. This feature will be even more powerful, when #62 will be implemented.
🔀 Alternatives
Naming of the methods can be adjusted (e.g. AfterSuccess/AfterFailure or WhenTestSucceed/WhenTestFailed). I don't have any different and rational solution for this use case.
💡 Possible implementation
To make this working as expected and avoid chaining of multiple invocations of the same method, there three new interfaces has to be added:
public interface ITestResult
{
ISuccess WhenSucceed(Action<Response> onSuccess);
IFailure WhenFailed(Action<Response> onFailure);
}
public interface ISuccess
{
ITestFinished WhenFailed(Action<Response> onFailure);
}
public interface IFailure
{
ITestFinished WhenSucceed(Action<Response> onSuccess);
}
public interface ITestFinished;
This way, return value from Test methods have to be ITestResult, respectively Task<ITestResult>.
With this architecture, methods have to be meaningfully implemented in some concrete types.
➕ Additional context
This feature can support ideas in #65 from different perspective - programmatically.
🫴 Proposal
After a test execution there can be different behavior when test succeed and when the test failed. This feature should add two new methods
WhenSucceedandWhenFailed, which can be fluently chained after test method, like this:✨ Motivation
Sometimes, set of tests are dependent on each other and failure of previous can cause failures of following tests. To prevent such a behavior these two methods can logically separate the flows after test execution according its result. This feature will be even more powerful, when #62 will be implemented.
🔀 Alternatives
Naming of the methods can be adjusted (e.g.
AfterSuccess/AfterFailureorWhenTestSucceed/WhenTestFailed). I don't have any different and rational solution for this use case.💡 Possible implementation
To make this working as expected and avoid chaining of multiple invocations of the same method, there three new interfaces has to be added:
This way, return value from
Testmethods have to beITestResult, respectivelyTask<ITestResult>.With this architecture, methods have to be meaningfully implemented in some concrete types.
➕ Additional context
This feature can support ideas in #65 from different perspective - programmatically.