As you alreay read or heard Microsoft released the ASP.Net MVC 1.0. From my perspective it is a step in the right direction.
MVC is not just a pattern, it is about software quality and professional software development: In my eyes a professional software developer is concerned that there exists a seperation of concern in his program code and he wants to deliver the best possible software to the customer what he can create.
Both concerns are reachable with the MVC framework. To ensure the quality, do unit testing (one of the first things when you create a new MVC project in VisualStudio is to decide if you want to create a test project – do not press the cancel button!), to ensure the seperation of concern principle, follow the rules of the framework.
Here serveral interesting links:
- Sample chapter, a hands on labs
- Sample application
- More sample applications
- More about MVC
There exists a project at Microsoft which generate unit tests based of source code. The name of this interesting project is Pex.
At the first time when I heard about this project I was skeptical.
- Where’s the value of generated tests?
- Doesn’t it break the “test first” approach?
After I saw this screencast from the PDC 2008, I could find the answers for me:
There is a value: It is often tedious to write all the unit tests with the extreme values which could pass to the method. For this tedious work it’s nice that you could generate all this “technical” unit tests. For this reason I would create an assembly where I would generate all this unit tests and separate them from the other unit tests, which I wrote by hand (and with the “test first” approach, like TDD).
The answer for the second question if it brakes the “test first” approach, is yes. But it isn’t a bad thing by nature. The generated tests are more technical stuff and they don’t serve as examples or specification.
There is a little differences how C# and Java implement the switch-statement. I discovered it when I want to implement a fall through in C#.
In Java it is very simple: just leave the break statement at the end of the case block away.
In C# it doesn’t work like that. There is no implicit fall through (with one exception: The case blocks have to be empty). You have to implement it explicit by add at the end of the case block a goto statement which refer to the case block which should be called.
The advantage of the explicit way is, that a classic mistake couldn’t happened but the disadvantage is that you have to write more code and use the “old” keyword goto (and I thought I wouldn’t see this keyword again…). I found also an explanation for that behaviour on msdn.
Since the 19th february I am Sun certified Java programmer (Standard Edition 6).
When you use a code coverage tool one of the first question is what is a good code coverage. Recently I listened to different podcasts (stackoverflow, scott hanselman) where they discuss this topic. I wasn’t really surprised that there wasn’t one unique opinion.
One opinion was that 100% is a good number, an other opinion was that for non-failing code it doesn’t make sense to build a test, so 100% isn’t a good number for most of the projects.
The last opinion sounds not that bad, but for which code it doesn’t make sense to build unit tests?
Here is a (not complete) list of code elements for which I wouldn’t build a unit-test:
- Properties (.Net)
- Getters (Java)
- Setters (Java)
- Primitive Constructors (no chaining, no big logic in it)
- Services (which just delegate to the business logic)
- GUI (Views)
- Data Access (do not test a framework)
- Services of another component or another application (do not test a library or another application)
- Any Generated Code (do not test a tool, in this case a code generator)
Is there a code element or type which I forget?
