Isolation of Test Data from Organization Data in Unit Tests

Starting with Apex code saved using Salesforce API version 24.0 and later, test methods don’t have access by default to pre-existing data in the organization, such as standard objects, custom objects, and custom settings data, and can only access data that they create. However, objects that are used to manage your organization or metadata objects can still be accessed in your tests such as:

• User
• Profile
• Organization
• AsyncApexJob
• CronTrigger
• RecordType
• ApexClass
• ApexTrigger
• ApexComponent
• ApexPage

I disagree strongly with your assessment of how @IsTest annotated classes should work.

As per my understanding and salesforce documentation, class annotated with "@isTest" sshould [sic] have "only test methods".

As you note, you need to be able to write test utilities. For example the following is perfectly acceptable:

@IsTest
public with sharing class AccountTestUtility
{
    public Account buildAccountWithName(String name)
    {
        return new Account(Name=name);
    }
}

It could certainly be made more generic and flexible, but there's no problem with the method not being a test method.

As for coverage, the R&D team should be working on fixing this Known Issue: Non-test methods in a test class are counted as part of Apex code Coverage. Note, however, that @TestSetup annotation is not a workaround, and suffers the same limitation (bug).

Regardless, when you use @TestSetup, the only thing you can do is create records that will exist when your tests run. Static and instance variables you set in this method will not still be set when your tests run.

If you would like to make it possible to have static variables you can set from @TestSetup methods, vote for this Idea: Remember static variables set during testSetup annotated methods.

However, it looks unlikely to be released. The last comment from the product team:

We intentionally clear out static variables between each test method. If we did not, each test would cease to be an independent trial. You could modify the static in one test method, which would make the order in which tests operate relevant to the results. This is precisely what you don't want - data dependent tests.

If you want information that is common to all tests, it can be inserted in the test setup method and queried in each test method. The idea here is not to reduce the number of SOQL queries, it is to reduce the amount of data being inserted into the system. If you insert 1000 records in test setup, run fifteen test methods, and you run a query 15 times to get the 1000 records each time, that's still less expensive (and faster) than inserting 1000 records 15 times.