3

I have test files in a order as shown in below image,

enter image description here

When I run npm test or jest __test__ , test files run in random order every time.

I want fix order as below

001_user.test.js

002_project.test.js

003_model.test.js

How to achieve this?

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
Swapnil Kotkar
  • 121
  • 11
  • 1
    Tests should be independent, so order shouldn't matter. – jonrsharpe Feb 26 '23 at 19:32
  • In my case I am creating user first then I will create project based on that user. so... test files order matters to me – Swapnil Kotkar Feb 26 '23 at 19:47
  • So don't. Create a _new_ user for the project tests. Otherwise you can't run _a_ test when you want to narrow down on specific functionality. – jonrsharpe Feb 26 '23 at 20:16
  • Test order does matter. I'm converting a project to use Jest and there are many errors. Each time I save, it gives me the errors in a different order, which makes it very difficult to deal with any one specific problem. – maccaroo May 30 '23 at 07:14
  • This can be achieved by using a custom testSequencer: https://stackoverflow.com/questions/49247539/how-to-make-jest-run-tests-in-a-specific-order – Matti Lehtinen Jul 29 '23 at 07:31
  • @jonrsharpe I do not find your comment in this generality useful. I think, one should always strive for test independence and it should be the default. But sometimes, you are confronted with e.g. REST API systems not under your control, that you can not easily setup to a specific state before integration testing. A sensible thing for lets say testing CRUD would be to sequentially call create, read, update, read, delete. If your only entry point is the API, it is perfectly reasonable to sequence tests – Marius Schmidt Jul 30 '23 at 17:37
  • @MariusSchmidt that's no argument for order-dependent tests. If you're writing integration tests with no better way to setup/"arrange" than an API call, it's _still_ better to do that in an independent test. – jonrsharpe Jul 30 '23 at 18:18
  • @jonrsharpe And how do you achieve independence, when the API forces you to create tightly coupled resources A, before you can create child resource B and then C? You could have one "independent" but bloated test with assertions along the way. But that collides with the best practice of one assertion per use-case and makes broken pieces harder to spot. In Junit5, I use test ordering rarely, but my described one would be such a case. But maybe I do not fully understand, what you propose? – Marius Schmidt Jul 30 '23 at 21:03
  • @MariusSchmidt having multiple dependent test cases, that have to run in a particular order, is the same as the "bloated test" except that you're _pretending_ they're separate. You can't focus one and run it, because its preconditions aren't actually expressed within the test case. If one fails, the downstream tests will fail too. "One assertion per use-case" isn't generally true, and can't apply to integration tests with highly coupled resources. – jonrsharpe Jul 31 '23 at 12:30

0 Answers0