-
Notifications
You must be signed in to change notification settings - Fork 0
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
Assess if TestFramework needs pre-execute and post-execute steps #10
Comments
AND/OR: would it make more sense to raise events? So E.G. at the start of each test block, we raise an event to let people either handle it for logging/test block setup/etc., or just ignore it. |
Given a common test base class, why not simply a set of virtual methods that can be overridden? |
Oh yeah... that would definitely work for pre/post test case. I guess this would be more for if there is a need for /pre/post test block stuff, where we're still in the middle of our execute loop, but maybe need to respond to something (like do some more extensive logging before everything for that block is disposed.) Once we get v1 wrapped up, I'll play around with some different options. |
Not sure if this is the same or not, but we need something like an "AddFinallyBlock" method that we have on the Parallel Test Team that will execute test blocks even if the normal test run fails. E.G., if we need to do some data cleanup using the things registered in our ServiceProvider before disposing of said ServiceProvider. |
First use case noted: screenshots at the start, end, or both the start and end of test blocks. We have this functionality already in v1, so it's just a matter of implementing the virtual methods mentioned, and then providing an example of how to use them for screenshots. |
I'm thinking maybe a list of actions that a test author can register to get advanced logging on before and after states of tests and test blocks, pushing/fetching information from a DB, etc., and generally things that need to live between test setup/teardown and creating the actual test blocks to run.
To make this worth it, we may need to add some helper methods to fetch things like the names of test blocks (in order), any traits associated with the test case, maybe inputs/outputs, etc. As one example, something like:
TestBuilder.RegisterPreTestCaseAction(() => MyHelpers.SaveTestBlocksToDb(TestBuilder.FetchATestBlockMetadata()));
The text was updated successfully, but these errors were encountered: