I have run in to this situation where the data model is very complex and since SF doesn't support mocks (e.g., Mockito) there are so many SOQL executions in just setting up the data model (triggers, queries to get formulas, etc.) that the limit is hit. It is not uncommon to have a traditional web site / application that has a few dozen tables and likewise it is possible to build applications on Force.com that use a few dozen Objects, so I don't see this as unreasonable or a bad design issue. Also, in production it would never be the case that the entire data model would be populated in one transaction.
I surround the code under test with Test.startTest()/stopTest() calls which separates the setup SOQL limits, but I still hit it.
What we've done is to create a TestUtil class that has a Boolean triggersActive flag that we can set to false and then an areTriggersActive() method that returns !Test.isRunningTest() || triggersActive. In each possible trigger we call that method and exit out or continue on depending on the result. Then in the unit test methods we call TestUtils.setTriggersActive(false) on a case by case basis where necessary and where we can get away with not firing trigger(s). In some test methods we turn it on and off repeatedly.
I like the Idea of something like adding Test.startDataSetup()/stopDataSetup() methods as an enhancement, but barring that our triggerActive approach has "worked", but it is awkward to say the least.
I'm wondering if anyone else has encountered this and how they handle it?