This question is very likely to be an opinion based. Yet I'm sure that opinion backed up with solid arguments paves the way to sound decisions.
I do like to generate DB state using Autofixture.
I sincerely hate writing SQL scripts and then coding expectations 'magically' connected with assumptions of that script because I don't like when knowledge/logic spreads across layers/technologies.
I hate how tests fail when some column without default value is added to the table and we must manually edit all failing scripts even for tests that DO not use that column at all.
I like how easily I can derive expectations from DB's state or see how compilation fails when DB schema and hence classes change. And problems occur only with the tests which touch changed column.
My colleagues semi-bought the final argument but continue to insist that ease of debug is more important than brittleness of tests. They argue that randomly generated data is hard to debug and read, they insist that comprehenion of 4 screens of static/stable sql is much more easier than looking at code generating a collection of some objects and then setting 'tested logic affecting' properties values.
Their point is:
When I explicitly stated that entity A must relate to entity B and later I see that A relates to C I understand what causes the error. But it's hard to interconnect meaningless objects: B and C become indistinguishable by a human being. And to give the identity to the entity we must set other properties which do not affect the logic being tested.
I offered some compromise.
There is usually some kind of 'Name' property which we can manually set an so 'tag' the object.
Their unwillingness to accept the proposal gave me an idea to ask:
Ok, guys, let's forget about Autofixture with its randomeness for a moment and pretend that we just express DB state as POCO objects and persist them before calling the method under test. We loose the independence of construction logic but we still can explicitly set expectations derived from the state.
Actually I was surprised with the reaction:
To debug these I need to have Visual Studio opened and execution paused after data is persisted. However, we do not commit transaction - after the test all changes are rolled back. Hence, I need to read uncommited data from within SQL Management Studio. There are so many movements just for debugging a stored procedure. I'd prefer to write sql script rather than POCOS.
So for now it became a discussion about personal preferences and tastes. On the other hand it's very easy to become a biased passionate cherry picker and loose objectivity.
That's why I want to hear some ideas and arguments from the community.
