January 2007 - Posts
This is one of the posts where I should be going to bed rather than starting this but I just won't sleep if I don't post it. I was going over the comments in Ayende's post on Castle Igloo and noticed someone had posted this.
"Communication between a view and its associated controller is straightforward because View and Controller are specifically designed to work together. Models, on the other hand, communicate in a more subtle manner."
"Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling."
-- Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
In fact if you read Martin Fowlers essay on GUI Architecturer it captions a MVC UML diagram with
Essential dependencies between model, view, and controller. (I call this essential because in fact the view and controller do link to each other directly, but developers mostly don't use this fact.)
So the view and controller are tightly bounded and the coupling of the two in accordance with the pattern is ok. In that context webforms meets the defination of view (aspx) and controller (code behind) . The couple is one of web coupling, it's a web framework after all but you can't easily mock events or context data and although the couple is valid it quickly stands in the way of testability.
MVC frameworks that adapt to webforms extend the controller and view to reduce the couple so tightly. The view can register to the controller with out a strict contract, in this case what occurs is that the codebehind and view unify as one view and the controller a new class. By making the controller more like a class we can inject events and mocks to it with out a web context and increase testability in doing so. We do stretch things a bit here in a pattern layers sense as the view is now taking on events and data population passing to the code behind which in turn goes to the controller class so the code behind becomes a bit of a piggy in the middle between the pattern layers. When we consider MonoRail it has true degrees of seperation between pattern layers and testability to boot, best of both worlds.
As with any pattern is using what fits for you and your project, they are not set in stone and you can adapt where you see fit.
Ayende has a very interesting post on a new project from Castle called Igloo, a MVC implementation for webforms. Webforms are tricky to adapt to MVC or MVP because of code behind, it makes the view a two part visual and event controller that which in in turn makes the controller a two part controller class and code behind and in turn binds the view to the controller tightly. True degrees of seperation are lost.
Igloo does look to make the controller and view not aware nor dependent on each other. If you treat the code behind as a lightweight display mech and allocate more into the controller class then you have a good MVC approach. You will still have the problem of consuming events in the controller class from the view and removing web dependencies in the controller, the many problems of webforms. True MVC on ASP.NET is still the domain of Castle MonoRail but I will explore Igloo will interest.
Sean has announced
MbUnit 2.3 support in the ZaneBug GUI, this will be available in the ZaneBug 1.7 beta.
Some great articles from.
Jim (who looks so much like Robin Williams.....sorry Jim but you do :) and
James have a short interview on the O'Reilly windows dev center for their Windows Developer Power Tools book. The interview does mention about MbUnit's combinational testing and the book features row and combintional testing. Each section in the book is designed to be a overview to give you a taster of what each tool can do, I hope that folks do want to learn more about each tool featured in the book. I reviewed (along with
Phil Haack) the work Jim wrote for MbUnit, I was asked to write the section but a personal matter prevented that and Jim did some great work in giving us a presence in the book. Yet to make it to the errata but the URL for MbUnit is not longer MbUnit.org and is
MbUnit.com instead. I look foward to seeing this book in print!!
I was made aware of a few test questions that Microsoft ask as a first process to applicants on their student intern program. It's great to see these being asked and I figured I'd post up some pointers to help folks answer them as best as they can.
How do you test your code?
Answer should be "as much as possible" then explain how. If your a TDD fan then you can explain that and how you use it. If Waterfall, V-Model, RUP, CA and others are more your thing then explain how specification levels and testing meet. Either practice means testing and Microsoft will be interesting in hearing how you test. Don't lie however, your interviewer is likely to ask you about this question and if you know nothing about it then it will quickly show. Got tests on your project? Great explain a little about that, as a feeder for your interview.
Given a simple program designed to take inputs of integers from 1-1000 and to output the factorial value of that number, how would you test this program? You do not have access to the code. Please be as specific as possible
Note your not being to ask to code this question but consider first off what considerations you need to take before you answer the question. So given that the factorial number is any number that is 0 or above and the result of products of each number set you have 1 input and 1 output. So test fail conditions would be any negative numbers, 0 input value and a output value of 1, and incorrect results from a valid (0 or greater) input. Test pass conditions should test that a input of 0 equals a output value of 1 and that it take in every number bewteen 0 and 1000 and the expected result. You are testing every single range possible but the you run the risk of false postives raising from typos and other mistakes in such a big range of data. You could snapshot say 100 numbers that sample a different range and variance between 1 and 1000, this does mean that we can vary the number input range from each test to the next and prehaps expose errors.
Dan Bunea has written up a great article on
generating Ajax scaffolding with MonoRail, this extends the work that Marc Andre did on scaffolding support in
MonoRail.
Over the last few days I've relocated the MbUnit source from BerliOS to Googlecode, the main reason for this is to obtain a better SVN provider. MbUnit was first opensourced on BerliOS and while its proved a great host we needed a better long term solution that we can manage better. More and more folks are joining the ranks of SVN commiters so I felt it was vital that SVN management be easy, BerliOS sadly was proving to be a headache in this area. The bugtracker and wiki will remain as before, but links to downloads and other SVN data have been changed on the website and wiki. I have seen some interesting integration with wiki and mailing list groups which I think could be useful, Google also own a wiki company (I forgot the name) and with some potential blogspot integration things could get very interesting. If Google add a VS plugin to the bugtracker I'd seriously consider moving but as it stands JIRA is rocking for us.
Sam has a post on the latest TeamCity 1.2 release, this is a CI offering for Java and (unlike Bamboo) .NET from JetBrains. This release add's a VS plugin so you can see where unit tests have failed in your build direct in your code and a Visual Unsafe support. It also supports NUnit, NAnt and MSBuild. The downside is that it does'nt seem to support NCover/NCoverExplorer or tools like FxCop. I mailed them about MbUnit support (in my quest to get more tools supporting MbUnit) and lending a hand if need be, they mailed me back to say its due in a later version (possibly 2.0). What with Eric's new product coming down the line, its a cool next few months in CI land in the .NET space. CCNet IMHO still remains king in terms of tool support (supporting all of the things in the list of missing tool support in TeamCity), while it is in a development trough right now, thats the nature of OSS and things will pick up again.
More Posts
Next page »