This question is locked. New answers and comments are not allowed.
Quick question without going into too much detail. I am working on mocking out the database for unit testing of an IIS hosted WCF service. I was toying around with the idea of dependency injecting a context and possibly a transaction into a database handler and for unit testing only, have the transaction running with many, many FlushChanges() calls. Before I go through the effort of producing a proof of concept, what happens if I were to make a linq call on lets say a "Users" table (model.Users.Select(p => p).ToList()) for transactions have have been flushed but not committed? If I inserted a user, flushed it and then attempted a get, would I get back a user object w/its autoinc guid ID that otherwise would have been committed to SQL?
I realized this is not truly breaking the dependency on the DB but after a long running ticket with the justmock team and multiple samples going back and forth, I realized what I am trying to really achieve may not be possible. The "next best" would be running everything in memory without committing to the test DB which requires me to purge the data after every test run (not idea).
Thanks,
Jim
I realized this is not truly breaking the dependency on the DB but after a long running ticket with the justmock team and multiple samples going back and forth, I realized what I am trying to really achieve may not be possible. The "next best" would be running everything in memory without committing to the test DB which requires me to purge the data after every test run (not idea).
Thanks,
Jim