Thank you for the response.
I believe we'd agree that the state of the data should remain consistent for a repeatable test.
Two conclusions I drew, invocation of the integration methods retained a connection thus drawing an error not allowing the database to be dropped (error generated – “cannot drop database because it is currently in use”). If the goal is data integrity then it seems awfully expensive and time consuming to drop and recreate databases. Simply, cleaning up after oneself then starting a new is reasonable from a testability stand point. I guess my point is mainly the ladder. However, I think if this is the goal, then it would seem reasonable to write a stored procedure to clean the data, reset the identity keys and start anew. Maybe for readers of this information this is a good point to understand about the integration testing.
Once again, thank you for clarifying the reasoning behind the operations.
I believe we'd agree that the state of the data should remain consistent for a repeatable test.
Two conclusions I drew, invocation of the integration methods retained a connection thus drawing an error not allowing the database to be dropped (error generated – “cannot drop database because it is currently in use”). If the goal is data integrity then it seems awfully expensive and time consuming to drop and recreate databases. Simply, cleaning up after oneself then starting a new is reasonable from a testability stand point. I guess my point is mainly the ladder. However, I think if this is the goal, then it would seem reasonable to write a stored procedure to clean the data, reset the identity keys and start anew. Maybe for readers of this information this is a good point to understand about the integration testing.
Once again, thank you for clarifying the reasoning behind the operations.