+972 52-548-6969
.Net Testability
time to read 1 min | 111 words
Jeremy Millier really hit the nail on the head with this one:
I really think the .Net community needs to reexamine and debate the merits and appropriateness of the Visual RAD approach. A lot of what makes ASP.Net WebForms hard to test is the extra complexity that's there to support design time controls, specifically the page event cycle. RAD is doing more damage than good because the negative impact on maintainability/testability overwhelms the "write once" advantages of RAD.
Comments
I believe that the fundamental problem is that RAD makes for great demos and lousy maintainability. Wizards typically only help you the first time when creating a project, page, or other artifact. (There are a few exceptions where you can use the wizard to edit the item, but these are few and far between.) Unfortunately the majority of software cost is most often incurred during maintenance (and enhancement) and not initial development. So choosing tools that make initial development easier (i.e. drag & drop, wizardy stuff) and maintenance or enhancement harder is the wrong way to go, IMHO.
O agree with you 100%, the problem is that Microsoft is looking for great demos, and it build the tools accordingly.
True.
I used to be an ASP.NET control developer in my previous job and the time ratio between development of runtime features and design time features was about 1:9.
It makse us have bigger dll's blown up code and of course it is good only for Demos/Trivial scenarios.
No serious web developer that I know is using the dseign time features so it is also a waste of time and energy...
Do you also hold this view in regards to winforms, or only ASP.NET?
WinForms are a lot easier to test (in theory) because it is simple to simply pump the correct messages to the application.
From there you can start doing more interesting work. It is also the case that I can do a new Form() everywhere I want, which is an important quality when I need to test.
I'd agree in regards to WinForms. You can even treat small controls as just plain classes, and the MVP abstraction doesn't leak like WebForms.
Data binding is a pain though. I'd bypass data binding for non trivial cases if you want testability.
Because winforms are stateful, databinding can be a real killer here, especially when you want to do it two ways.
I tend to avoid it at all cost, I would rather write code to do the shuffling (or write a framework for it :-) ) than deal with it. About a year ago I spent a few days going over the databinding approach in WinForms.
It is very powerful, if you are using datasets.
Otherwise, it makes a lot of false assumptions (Like I would care to implement interfaces on my model just to get databinding).
Comment preview