December 22, 2009 Leave a comment
December 15, 2009 Leave a comment
I am preparing a Slide Deck on Unit Testing for my employer’s .NET User Group. The deck is pretty vanilla but it does help me crystallize my thoughts around dogmatic versus pragmatic unit tests. The purist argues that the unit test should be in complete isolation – it has no dependencies across layers and, therefore, needs a mocking framework to be used correctly. I take a more pragmatic approach – I am less worried about writing correct unit tests as much as writing effective unit tests.
I recently added some unit testing to a project for which I am tech lead. We implemented some unit tests that call an API that, in turn, calls a lower layer. The tests are clean and they are very effective at identifying problems when the code changes. Interesting, even though the unit test depends on some data in a database – they have yet to fail because of that dependency. It has failed for some failed logic introduced when refactoring though – proving the usefulness of the tests. If the tests do fail, the developers know that the error might be in the dependency and can investigate appropriately.
I think this example points to the heart of the unit testing – you either take ownership and use them effectively as part of the way you code, or you don’t. If you are in the former category, you can get away with dependencies in your unit tests. If you are in the latter category, you shouldn’t even bother with unit tests at all – correctly formed or otherwise.
December 8, 2009 Leave a comment
I was pulled into an IRT over the weekend. A development team was moving their application from DEV to QA and experiencing an unexpected error. They could not connect to the database from their web application. Turns out they had two databases on the same server and they could connect to one using a connection string like this:
connectionString="Data Source=DIXON08;Initial Catalog=VideoGames;Integrated Security=True"
but not the other one. After going through the typical algorithm of ports open, impersonation set correctly, etc…, it was found that the connection string needed to fully qualify the server name and the port like this (I didn’t come up with the right answer, Rob Seder did):
connectionString="Data Source=Com.Tff.DIXON08:8001;Initial Catalog=VideoGames;Integrated Security=True"
Why it worked on one database without fully qualifying versus another that did need it, I don’t know.
December 1, 2009 Leave a comment
I am getting ready for Microsoft exam 70-569 by going through their on-line learning courses found here. Last night, I did the lab for 6654. Things were going great until the last step – where you actually call there WCF Service, which then makes a database call. I received the following error:
Could not open database “Appointments” requested by login. The login failed. Login failed for user ‘LON-DEV/Student’
The problem is that the connection string is hard-coded into the supporting class that Microsoft provides and there is no other way to login. I am surprised Microsoft didn’t QA their applications better. I am also surprised that no one else hasn’t found this for Microsoft to fix…