I'm not sure what the acknowledged "best practice" is.

Some of this depends on the expected complexity of the test cases and if there is any substantial overlap required in terms of data or functionality needed to drive the tests for the five classes.

One thing I often do is to create a "test data" class which instantiates unique instances of the data that I'll need for a test.   I sometimes parameterize it so that the same code can create just one or two records, but can also create hundreds of records for bulk testing.    Then, each of the test methods for a specific Apex class can create an instance of that test-data class and create data as needed.

If you have utility needs for the test data that might only be needed by a few of the tests, you can also put those methods in the test-data class.   For example, let's say I'm writing a lot of code that deals with Opportunities.

Well, the Opportunities need a Contact, and an Account, so those have to be created as well.  (And they should be unique rather than reusing existing data in the instance.).  So, my test-data class would create the Account(s), Contacts(s), and Opportunities.  Perhaps you need one Opportunity for one test, but several hundred for another, so parameterize the test-data constructor.  You may also need just one Contact for all the Opps, or one per Opp, etc.   Different Users, etc.

Also, some of the tests may need some of the opportunities to have OpportunityLineItems.  So, perhaps a utility method in the data-class could add OLI's to the Opportunities.  (Not to mention the Products and PriceBookEntries, etc.)   This may not be needed by all the tests, but if it's needed by several, it's good to have it in one place.  

Also, I may want to have some common data-testing classes in the data-class so that I don't have to perform the same checks in several test class.  For example, if your tests want to check that each Opportunity has one and only one OLI, perhaps you could put that checking code in the data-class.   Likewise, sometimes you want to make sure the Opportunities have been deleted, or marked Closed, etc.  That common sort of testing code can live in the utility class.

Hope that makes sense.

Regarding the driving of the tests themselves.   If the testing isn't all that complex, there's nothing that stops you from putting the testmethod classes in the same Apex file as the Class being tested.   If it's pretty straightforward, that's a nice thing to do as it's all there in one place, easy to see and modify.

If the five methods will share a lot of the same procedural code to drive the testing (that can't be abstracted to a data-class as above), then putting them all into the same class is fine, however I sort of frown on it and would, instead create another utility class to hold the common testing code and put the unique code in the Apex class itself.

However, if, after all that, the unique testing code is large enough to be confusing, I'd put it in a class file of it's own.

Note that it helps to have naming conventions in place so that you can manage your testing code.   For example:

Controller_thisCoolVFPage

Test_Control_thisCoolVFPage

Test_Data_thisCoolVFPage

Test_Helper_thisCoolVFPage

Trigger_aStellarTrigger

Utility_Stellar_Cartography

Test_Trigger_aStellarTrigger

Test_Utility_Stellar_Cartography

Test_Data_Stellar

Test_Helper_Stellar

Or, you can group it differently, put them all under "Stellar_", etc.

Best, Steve.