What is the testsetup salesforce best practice?
I'm trying to understand something so I can use @testSetup annotation wisely. As i read here:
By setting up records once for the class, you don’t need to re-create records for each test method. Also, because the rollback of records that are created during test setup happens at the end of the execution of the entire class, the number of records that are rolled back is reduced
But if you run a test class, you can see that all of the DMLs are recreated for each test method and not just once.
So what is the purpose of using it if I need to add an extra SOQL to retrieve the data I created in each test method? why not just use it in the test class itself and use it directly? just to reduce code duplication?
The Test Setup salesforce method runs once and only once for the given test class (at least when running all tests; I'm not sure what happens if you run tests selectively, by method name).
When a test class is to be executed, if there's a setup method this is called once, always before any of the test methods are invoked (with these later running sequentially or in parallel, based on your settings). At the end of the setup execution the unit testing infrastructure effectively sets a database "save point". Each individual test is then run with the database set to that "save point". After all (relevant) tests are run, the database is reset to the state it was before running the setup method.
Note that each test is run in an isolated transaction on top of the "save point". It is for this reason that static variables set in the setup method are not retained.
This has several advantages:
The expensive DML operations are performed just once for a given test class (see comment above). This makes unit tests run faster. Sure, you have to run SOQL queries to retrieve the required record IDs you previously inserted, but this is far less expensive so you still win.
The setup is performed with some of its own governor limits (take a look at this Q&A for more info).
Since database isolation is a bit flaky in unit tests in certain cases (for example, when inserting custom settings records), this can cause DML errors when running tests in parallel (which you will typically want to do). By reducing the number of times data is inserted you minimise the opportunity to be tripped up by this.
The only real disadvantage is complexity in retrieving the IDs and data which necessarily happens in one or more other methods outside the setup (you could vote for this idea, btw). We address this by having a specific method(s), that we organise in the code to be next to the test setup method, that "get" the required record(s).