I am a huge fan of creating global test classes within Salesforce that leverage one testSetup section to set up the data that then can be used many times to test the many different methods and classes. Gone are the days of having a million test classes to manage and update every time changes are made in the system. I’ve been using this for over a year and as my classes have continued to grow in size and complexity I have run against one limitation that I was unaware of until recently. DML limits are reset when using testSetup but not SOQL limits. Specifically if when you insert a record if that DML generates SOQL statements, which I have a lot of code that relates and joins data, that limit is passed on to the test methods. I think because my test classes are segmented in to major functions I was not running in to a lot of overlap.
In reading the below StackExchange answer it is clear now that all of my test methods need to use Test.startTest() and Test.stopTest(). I always use these methods for scheduled or future class testing but now it is clear that I should be more diligent in always using them.
The tasty bits:
NOTE: If your org has events that are triggered from that INSERT (which you likely do), THEN any DML or SOQL statement that proceeds from those are considered outside the context of @testSetup and will impact your overall governing limits for your test class.
As always these limits are reset within any test method when you invoke Test.startTest(); and Test.stopTest(); but this could affect how much data you can setup within your data setup method (for example when cascading dependencies like Contacts, which need Accounts).