In short, all other things being equal, injecting the data into the database is the better approach. It reduces tight coupling between the separate business logic features. It also
I've struggled with the same question not too long ago. For reference, I finally convinved the PM to let me implement a basic amount of unit testing for a project that has been developed with no testability in mind.
The data in our project is shaped by a series of operations - the project is an application which performs these many operations. However, there is so much generated (meta)data in after the first X steps, that it became nigh impossible for me to generate the actual data state I needed to test (and in some cases there were 100+ combinations of data sets to test).
This was further compounded by the fact that the data structure was continually changing because of a bad and vague analysis and an equally vague project owner.
There are a lot of flaws in the current project management. The analysis should not have been vague. The code needed to be developed with testability in mind. The entire data structure should have been revisited instead of copy/pasted from the last similar project.
Nonetheless, this is the project I was writing unit tests for, so I had to face the facts. There were ulterior reasons (not directly related to my development) which made the proper approach (data injection) nigh impossible to get right.
At this point, I decided to therefore rely on the business logic to arrange the state of the database.
Am I happy about it? No. It feels so very dirty. However, I do have to admit that it does actually work given the less-than-perfect situation the project already finds itself in.
The biggest drawback here is that a small error in one of the first operations will cause many tests to fail, since almost all subsequent operation logic depends on that first operation to be correct.
But due to the linear nature of the operations, it's still relatively easy to spot which test is the cause. We actually ended up numbering our tests so that the order of operations (and thus the order of tests depending on each other) became obvious.
By default, I do not recommend choosing to rely on the business logic to set your data state. However, there are some situations where the data is so complicated and you're unable to actually change that fact. In those situations, it may be beneficial to simply have the logic generate the data state for you simply to ensure that you can have some tests instead of none at all.