If you have the logic in the stored procedure I'm not sure you can effectively do "unit tests".
What you can do is setup the database, run the stored procedure and then verify that the data is how how you expect it after the procedure is ran which you're already doing if I'm not mistaken.
This is probably more of a functional test than a unit test but if it's reproducible (given the same base data setup) without side effects (it doesn't send millions of emails :D) it should be testable.
Does it really matter if it's not strictly a "unit test" ? I'd say "who cares" :-) Your business logic is tested, battle test your stored procedure for various sets of inputs like for example what happens with null values, check if there is any order precedence and so on.
I assume you put the logic in the stored procedure because the domain logic was too slow for your use case :-)
I have over 20 years experience primarily developing line of business applications, for a UK clothing retailer. My mantra is good naming convention trumps everything!!
@rhymes
, thanks for responding with your thoughts.
In terms of the database, we have a Visual Studio Database Project, this provides a "Dacpac" including specific pre-canned data for our tests. The test suite then uses the Dacpac to drop and create the database when the tests run. This means the data is consistent on every run.
The original reason for not placing the business logic in the domain was actually because we're implementing a CQRS style of design. It's not full on CQRS, but it does mean that we've got a query only path in the application. This particular query sits on the query side of the application. It's only after we knocked up the stored procedure that i realised that we were actually implementing business rules in the query and that they should really be tested.
It sounds like, from your point of view, that the approach we've taken makes sense to you. The more I explain it, the more comfortable I am becoming with it - certainly from a pragmatic point of view
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you have the logic in the stored procedure I'm not sure you can effectively do "unit tests".
What you can do is setup the database, run the stored procedure and then verify that the data is how how you expect it after the procedure is ran which you're already doing if I'm not mistaken.
This is probably more of a functional test than a unit test but if it's reproducible (given the same base data setup) without side effects (it doesn't send millions of emails :D) it should be testable.
Does it really matter if it's not strictly a "unit test" ? I'd say "who cares" :-) Your business logic is tested, battle test your stored procedure for various sets of inputs like for example what happens with null values, check if there is any order precedence and so on.
I assume you put the logic in the stored procedure because the domain logic was too slow for your use case :-)
@rhymes , thanks for responding with your thoughts.
In terms of the database, we have a Visual Studio Database Project, this provides a "Dacpac" including specific pre-canned data for our tests. The test suite then uses the Dacpac to drop and create the database when the tests run. This means the data is consistent on every run.
The original reason for not placing the business logic in the domain was actually because we're implementing a CQRS style of design. It's not full on CQRS, but it does mean that we've got a query only path in the application. This particular query sits on the query side of the application. It's only after we knocked up the stored procedure that i realised that we were actually implementing business rules in the query and that they should really be tested.
It sounds like, from your point of view, that the approach we've taken makes sense to you. The more I explain it, the more comfortable I am becoming with it - certainly from a pragmatic point of view