[SalesForce] Best Practice while using Test.startTest & Test.stopTest in Test class

Unfortunately, no. While you can have all 200 tests in a single class, you'll still need 200 unit tests. Test.startTest() will throw an exception if it's already been called, and Test.stopTest() will throw an exception if it's already been called.

You can, however, use @testSetup to set up all common data first before running your 200 tests-- they'll only count for the governor limits once and save you execution time (usually by many minutes).

@isTest
private class Sample_Test {

    @testSetup static void testSetup() {
         // Set up common data here
    }

    static void printTest(Integer i){
         // Query your data from testSetup before starting test
        Test.startTest();
        system.debug(logginglevel.ERROR, '$$$$$$$$$$$$$$$$$$$$$$$ ' + i);
        Test.stopTest();
    }

    static testMethod void sample_test_method_1() {
            printTest(1);
    }
    static testMethod void sample_test_method_2() {
            printTest(2);
    }
    static testMethod void sample_test_method_3() {
            printTest(3);
    }
    // ...
}

I've been struggling/battling with this since the Spring '13 release.

It tends to manifest in one of two ways when parallel testing is enabled:

1. As you found, Tests fail with APEX CPU Timeout Exceeded messages, or
2. Entire tests classes fail with Could not run tests on class 01p400000000001 because: connection was cancelled here messages.

The sad truth is that data created and used in Apex test cases isn't fully siloed (as at Summer '19). Not so much in that actual data will seep from one tests to another. But more that the indexes and unique constraints that are enforced in the database cause deadlocks between test cases.

There is even a section on this in the Developer Docs now under Best Practices for Parallel Test Execution: (my emphasis)

Tests that are started from the Salesforce user interface (including the Developer Console) run in parallel. Parallel test execution can speed up test run time. Sometimes, parallel test execution results in data contention issues, and you can turn off parallel execution in those cases. In particular, data contention issues and UNABLE_TO_LOCK_ROW errors can occur in the following cases:

• When tests update the same records at the same time. Updating the same records typically occurs when tests don’t create their own data and turn off data isolation to access the organization’s data.
• When a deadlock occurs in tests that are running in parallel and that try to create records with duplicate index field values. A deadlock occurs when two running tests are waiting for each other to roll back data. Such a wait can happen if two tests insert records with the same unique index field values in different orders.

What can you do?

1. Ensure that you aren't using @IsTest(SeeAllData=true) anywhere in your tests.

2. Turn off parallel test execution and take the hit in how long it takes to run the tests synchronously.

3. Attempt to completely bypass the DML operations via mocking. How practical this is will depend on the complexity of your tests.

4. If you detect failures during test execution, run those failing tests again until the results stabilize. So far this is the fastest way I've found to handle the non-deterministic nature of running parallel tests.

   This is more or less what I've been doing day to day. Since the SFDX CLI didn't exist when I needed it I did this directly against the Salesforce APIs. It's available in the FuseIT SFDC Explorer. (A free tool released by my current employer). On the "Apex Tests Queued" tab keep running the tests with "Run Selected Tests". It will only run the tests that failed in the last run. Gradually you will end up with just the tests that are actually failing.

5. Vote for the idea Control the degree of parallelism when running apex tests in parallel. Right now Salesforce will try and run up to 30 tests in parallel. It's kind of crazy when combined with the potential for deadlocks. A much lower degree of parallelism would still allow for faster overall test execution while reducing the chances of deadlocks.

6. Vote for the idea Parallel Tests Option (isParallel) on the @IsTest Annotation to exclude tests. Some tests are just never going to play well with others. But that doesn't mean we should give up on running the other tests in parallel.