Developed to help introduce key topics in Test Driven Development, for new and veteran developers alike. Some examples are language-specific (C# / MSTest / Moq), but the principles apply to any object oriented language.
Recently I have been looking at ServiceStack's OrmLite "Micro ORM" as a light-weight alternative to Entity Framework. It is relatively easy to use and very powerful, with capability for both code-first and database-first development. After learning the basic interaction, it was time to flip back into TDD-mode.
And then I found quite the challenge: I wanted to write unit tests that insure that I'm using OrmLite correctly. I was not interested (for the time being) in testing OrmLite's interaction with SQL Server itself. That is, I wanted behavioral unit tests rather than database integration tests. Time for a mock. But what would I mock? This ORM framework makes extensive use of extension methods that run off of the core IDbConnection interface from the .Net framework - so it would seem that there is no way to take advantage of Dependency Injection.
how do you use Entity Framework, in database-first mode, when
following the dependency injection development patterns?
Answer: take advantage of partial classes and manually create the interface. The following notes are just a sketch without full details.
Executable tests are the best form of requirements documentation. They improve quality through early discovery of bugs and by fostering a more detailed "what-if" analysis: what if we have this input X? What if the user does Y?
Follow-up to Building a Test Script Environment with C# and IronRuby, pt 1, wherein we change emphasis from coding tests in Ruby to writing them in English (Gherkin) with the help of SpecFlow.
After that October post, I managed to construct a full system/regression test suite for a key data-management application, using the combination of Ruby and C# as described. My team has been able to go through several cycles of…
We build a lot of console applications, and Windows services, that process inbound and outbound files in one way or another. Most depend on configuration data and some load (or unload) business data from a database, in addition to accessing the files. Testing these has always been a chore, to say the least: configurations change, data are deleted, and there's never enough time. After building a few rudimentary tools that have helped, necessity, and Agile Testing: A Practical Guide for Testers and Agile Teams, has convinced me that it is time to get serious about system/integration test automation, just as I did about unit test automation a few years ago. This is the first of a n-part series of posts on this process
Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce
I did not realize how much I still have to learn about writing good object-oriented (OO) code, and about hewing to a tight test driven development (TDD) methodology, before I read Growing Object-Oriented Software, Guided By Tests. My education in OO and unit testing has been largely theoretical, with no time spent directly learning from experienced OO programmers; my best mentor was a COBOL coder. Books like Design Patterns: Elements of Reusable Object-Oriented Software ("Gang of Four"), Patterns of Enterprise Application Architecture, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Xunit Test Patterns: Refactoring Test Code, and others are wonderful but have few detailed real-world business-case examples.
Test driven development is hard. Perhaps it would not be if we were taught to think about OO development from a TDD perspective in the first place; but those muscles are poorly developed, and the exercise leaves you sore and panting a bit. As with physical exercise, there is a reward in the pain. Perhaps others do not see it, but I can already see the benefits accruing in Reggie as I rebuild it with SOLID principles in mind, driven by tests. To help me consolidate where I’m going, and help others whose TDD muscles are likewise under-developed, let us walk through a test, shall we?
First, some context. I’m working on adding persistence to the application: ability to save and re-open session data. I have a ViewModel, called ReggieBasicViewModel, which initially contains the data to persist and which binds the View to my business logic. The ViewModel is being instantiated with a factory object, which allows the ViewModel to build concrete instances of various dependencies. This illustrates the Abstract Factory pattern, and the Open-Closed Principle, but arguably violates Single Responsibility Principle [same link as OCP] by grouping un-related functionality into the factory. The proper factory object is configured in the application’s bootstrapper class, or or it is setup in a unit test using an alternate factory implementation.
Moles is a powerful and useful framework for unit testing. Or was. But even then, it was overused (at least by me). But no more!
The first clue that I might need to walk away from Moles was the recent difficulty another developer was having in trying to get a unit test project up-and-running on his computer. I had installed what was current in early 2011, and he had installed the current version from last 2011. Turns out there was a significant change – the config file no longer worked. We had to update the assemblies correctly on my machine, rebuild many times, and fool around with manually removing some assemblies. It got confusing and messy. I suppose that's why MS still labeled this version as < 1.0.
For several years now, I have been relying on Microsoft’s Moles for isolating one method from another in my unit tests. Recently I’ve begun to understand that this was not the best approach. I’ll dig into that more in a future post. Having come to this conclusion, I need to start ripping out Moles. Based on the user feedback across the web, and the powerful Lambda expression syntax I’ve grown used to, I’ve chosen MoQ as my replacement. Now for an exercise…
