We are extensively using Redwood’s scenario system in our api side tests. Running the api side tests is taking well over 10 minutes, so we have been looking at some ways of optimizing this. To date, we’ve been focussing a bit on reducing the number of database records in the standard scenario setups. We’ve been moving database records that are infrequently used in the tests from the scenarios into a seed function in the specific tests where required. Using this concept, we’ve made a small, minor dent in our test times.
One thing I’ve noticed is that Redwood is, as part of every test wrapped in scenario
, creating all the scenario database records and then destroying all the records on each test. However, there are numerous cases where we are not modifying the data as part of the test. For example, tests of queries and all the mutation tests that should fail shouldn’t touch the underlying db records.
What are your thoughts on having a version of the scenario setup that allows nested it
test statements within an overall wrapped scenarioSetup
function? That is the scenarioSetup
function would not actually run any tests, just do the database setup and destroy. Yes, there is some risk of test contamination, but the user could determine when there would be a benefit to this vs the current scenario
call.
Something like the following:
scenarioSetup(standard, async (scenario: StandardScenario) => {
it('does thing A', () => {
... test 1
})
it('does thing B', () => {
... test 2
})
})
Would appreciate any feedback on this concept.
@rob, I believe you are the original designer of these scenarios… do you have any thoughts on this?
@MichaelrMentele, I understand from your talk at the conference that you’ve possibly taken a different approach than scenarios in your testing, and would love your take on this as well.