We all profess test driven development and we should. Sometimes pushing MVP to the market in certain time is important and we skip tests at all.
Whatever the case, write tests for your code as soon as you can.
But with huge code base, and good test means you will have hundreds if not thousands of tests to run. And all those tests could include some preparation computation before we execution and clean-up after it. There are separate strategies to optimise that much in-nutshell: tests could take a lot of time to run. Often we run those test for automatically at merge and pull requests.
That require a lot of compassion on cloud and hence cost you fortune.
Read about development pipeline strategies here.
So, it would be better to run only test related to the feature changed, if its UI test run test for the concerned page, and not for something that stay unchanged.
Here we will see an example how to do that if you have your code hosted on Github and CI done via Github actions, but these strategies works for other tools too.
Lets, assume we are doing UI tests and our code is structured such that we have scr/pages folder that contains components for all pages eg: src/pages/register , there could be subdirs as well eg: src/page/register/shared, src/page/register/styles etc.
Now in your Github action where you run tests
- Get files changed: For Github Actions you can use Changed Files action from action market place
- Filter files from your pages directory, get pages names keep unique only, that's where you UI components are right?
- Pass this list to whatever testing library/suit/runner you are using, be it JEST, playwright. Let your runner only run those test only.
Warning: If you have shared components which are used on multiple pages, make sure if there are any changes in those, run all tests to be sure you are not breaking anything.
Comment about your approach to tests and have you run into this issue of insane time to run tests.
Top comments (0)