I am pleased to announce that the next installment in the Autumn Of Agile screencast series is now available for immediate download from the main web site.
Good news, Bad news
The good news is that this is the installment where we finally start to write some code! The bad news is that this installment clocks in at nearly two hours in length (and about 200MB) owing to the wide variety of things that are covered in this one…
- TDD Concepts and practices
- Configuring Testdriven.NET keybindings in Visual Studio for speedy test-runs for easy TDD
- Iteration and Release Planning in TargetProcess
- Using the TargetProcess Visual Studio plug-in to manage assigned work
- Getting our CI Server to run our first unit tests
- Wiring up our Domain Classes for easy persistence support using common base-classes
- Leveraging NHibernate mapping files to drive the auto-generation of our database schema
I Promise: Sensible length in the future!
Subsequent installments should be a bit more sensible in length; this one got a bit out of control because of all the ‘foundational’ concepts that needed to be put together to support the development of our first User Story. Now that this is all behind us, subsequent installments can (hopefully!) be a bit more focused and of a more reasonable length (1.5 hours is my practical target goal).
Schedules and Burn-Down Rates
More good news is that the pace at which I am blowing through the tasks in the User Stories is faster than expected. In the two hours that I spent for this Part A of the first iteration I completed about 50% of the first user story that was estimated at 9 hours in effort. That’s a burn-down rate of 2.25x the original estimate (9 hrs X 50% complete / 2 hrs spent = 2.25). If I can maintain that burn-down pace against the backlog throughout the entire project then its at least conceivable that I could complete even the user stories flagged as ‘nice-to-have’ by the end of the series.
But experience has taught me that the burn-down rate in a single iteration (and especially that of just half of the first iteration) is a terrible predictor of maintainable burn-down throughout an entire project, so I’m happy but cautious at this point based on present rate-of-completion of User Stories. I may be off to a good start, but I don’t have near-enough data upon which to base a positive projection for the life of the project yet.
Coming Next: Rhino.Commons and ASP.NET MVC
In our next installment we will dive into the Rhino.Commons framework and begin to understand how it grants us power over the unruly nuisances of an NHibernate implementation for data-access and will stub out our first user interface page using the ASP.NET MVC framework as we try to complete our first user story.
As always, comments, feedback, and (constructive) criticism are welcome. Happy viewing~!
Hi, thanks for very interesting video-s , especially for summer of nhibernate, but i wanted to ask how to test a winform app. I’m using nhibernate for winform, but i have no idea how to write a test, test it. Any help?
there is no bad news i take that as a good news too 🙂
thanks for your time and videos
looking forward to see more in future.
Testing a winform app is actually much easier than testing a webforms app as its easier to ensure separation of concerns in a winforms context (no nasty coupling to HTTPContext HTTPSession, and other stuff that has been the bane of webforms testing in ASP.NET since its original release (and one of the driving factors in the upcoming ASP.NET MVC framework from MS).
If you have followed appropriate Single-responsibility-principle/Separation-of-Concerns in your winforms design, testing its data-access should be simple (relatively) compared to webforms issues. Is this a Q about testing data-access in a winforms app or testing the UI (or testing in general)…?
Thanks for this video Steve, it’s very very interesting to see in real how to use this kind of process. You didn’t start the counter on “TargetProcess Window” normal ?
Oops! You caught me~! That was an oversight 🙂
Any particular reason why you prefer to use MVC rather than MVP pattern? I hope that this will educate more readers as well for this query.
Thanks anyway, this is really brilliant idea.
I have used MVP as a pattern when doing winforms and (with a bit more effort) webforms projects in the past with great success. I firmly believe that for either of those UI frameworks, MVP is the best UI pattern to implement because it gives you the best-achievable separation of concerns, the highest flexibility in your designs and the highest level of testability you can achieve in either of those platforms.
But anyone who has tried to get the MVP pattern to work in webforms will know that you have to do it by ‘fighting’ with the underlying webforms infrastructure rather than working with it. MVP can be made to work in webforms, but there is a significant underlying feeling of ‘square peg, round hole’ to anyone’s final implementation. Webforms just isn’t ‘friedly’ to MVP though you can (and I have) implemented it with success on webforms projects.
When Microsoft announced their ASP.NET MVC framework, it was done with a focus on proper SoC, SRP, etc. software design principles that lead ultimately to a much more maintainable and testable application. I can get what I want out of a web UI framework with ASP.NET MVC without having to ‘fight’ with the underlying platform (too much!; there are still some awkward pain points in ASP.NET MVC that I wish would be resolved).
As such, I think that I am now at a point where the ASP.NET MVC framework will be my ‘default’ way to build a .NET web application (like the SkillPortal Project) and that I will have to be convinced that the situation would call for ASP.NET WebForms before chosing that platform again.
Note that this selection of ASP.NET web UI platform (ASP.NET MVC vs ASP.NET WebForms) isn’t so much of a decision on my part about the merits of the MVC pattern vs. the MVP pattern but is instead an acknowledgement that ASP.NET MVC is better than ASP.NET WebForms (even when used in an MVP pattern) and so that has lead me to a choice of MVC over MVP. If Microsoft had released the ASP.NET MVP framework, I might have a fair comparison to make 🙂
Hope this helps clarify where I’m coming from.
It’s may be because the MVC is implemented by Microsoft (still in beta) and not the MVP. Steve you talk about the “MVC Framework” by Microsoft ?
Question was about testing in general. I wanted to use SharpRobo tools, but i vanished.
Generally, automated testing at the UI layer is hard/brittle/complex even with appropriate tools and this is generally why you want to look to design your winforms -or- web apps such that its possible to test nearly all your logic independent of exercising the UI itself.
With the web, since the results are just HTML in your browser its easier for 3rd-party/OSS tools to automate reading results and sending HTTP requests to your actual applicaiton and so things like WatiR, WatiN, Selenium, etc. have grown up to address that need. Winforms, however, is a very different beast since its UI ‘output’ is much harder to ‘intercept’ in order to see responses and automate control clicks, etc. There are a number of commercial packages out there that address this need (sounds like you are already aware of some yourself) and even the seemingly-defunct NUnitForms project in the OSS space, but -generally- these are awkward and brittle automation tools that provide a dubious ROI (IMHO) unless your UI is really stable (not many design changes between iterations).
Overall, except for some corner case projects where it makes sense, I recommend people try to stay away from UI automation testing as its is rarely worth the hassle (sorry, UI test automation vendors, that’s just my opinion based on my experience).
As an aside, I heard a very interesting thing about UI automation testing under WPF: the accessibility API (designed to allow visually-impaired users to interact successfully with WPF apps) seems to expose a large API surface that I have heard makes automated UI testing of WPF apps a more reasonable goal than is the case for ‘traditional’ winforms apps, but this is just something I read/overheard somewhere rather than my personaly experience so YMMV.
Good luck and hope this helps~!
thanks it was great screen cast i just finished.
thanks a lot for sharing your knowledge with us..
Thanks for another great series – I’m hooked.
I’m really looking forward to the upcoming Rhino.Commons discussion in the next segment.
Any particular reason you are choosing to use ASP.NET MVC over something else, say MonoRail? Do you think MVC is baked enough that you would use it on a real project? Just curious, since I know your stance on beta sofware…
That’s really a great question (and I thank you for pointing out that my prior-stated stance on NO BETA FOR PRODUCTION WORK seems in conflict with my choice of ASP.NET MVC for this series/project). I appreciate your keeping my honest 🙂
My reason for choosing ASP.NET MVC (even tho its still in BETA) is the same as my choices for other technologies: I am splitting the difference between ‘technology has to provide significant value’ and ‘technology has to be of interest to as many people as possible’. This is largely the reason for my choice of ASP.NET MVC over MonoRail (with which I also have experience I could share).
Sadly, although monorail had ‘first-mover advantage’ (or if not first, certainly gained the most traction IMHO among .NET developers interested in an alternate to ASP.NET Webforms), it never really saw terribly broad adoption. With ASP.NET MVC’s impending release, there is a chance that some of the mindshare that its getting will spill over into MonoRail when *some* will discover many things that MonoRail does better than ASP.NET MVC, but my sad expectation is that this will not manifest itself in a big way.
I don’t expect that the interest in ASP.NET MVC is going to significantly increase the adopters of MonoRail in the same way that something like Unity has increased the number of Castle Windsor, StructureMap, NInject, etc. adopters or that Entity Framework has increased awareness of NHibernate.
I actually think this is for several reasons:
1) EF and Unity aren’t really entire ‘platforms’ (despite MS PR to the contrary!) in the same way as ASP.NET MVC is
2) its very likely that a third-party product ecosystem (control vendors, etc.) will grow up around ASP.NET MVC in the same way its done around WebForms and this is not expected to happen to MonoRail anytime soon IMHO; this will further stiffle an increase in MonoRail from ‘dissatisfied ASP.NET MVC adopters’
3) The very real limitations of Entity Framework and Unity are things that any real-world dev would bump into almost immediately upon their first real-world/non-demo use of these technologies and so anyone serious about ORM or IoC quickly looks for another solution and usually finds it in OSS. The limitations of ASP.NET MVC are a bit less i-your-face and tend to be exposed only by less-common edge-cases and so adopters of ASP.NET MVC aren’t as likely to get dissatisfied so quickly and look for alternatives (MonoRail) in the same way
Sorry this is a bit long-winded, but if you regularly visit this blog or watch my screencasts, I’m sure you’ve come to expect nothing less from me 🙂 but the answer to your last question of “do I think its stable enough to base a real application upon?”, the answer is YES. On my own team at my company we have two such projects underway right now that we are basing upon the ASP.NET MVC BETA platform but are expecting to complete 1Q2009 at which time we expect the final RTM bits to be completed.
The success of StackOverflow as a viable site on this technology (technically still based upon the preview bits and not even the BETA release AFAIK) has given us the confidence to proceed this way and I’m letting that confidence spill over into the SkillPortal project for this Autumn of Agile series too.
Thanks for the insight Steve. Those are all very good reasons 🙂
Will the Microdesk.Domain.Foundation library be released?
You almost showed it all…except for IPersistentObject 🙂
Yes it will 🙂 under the same ‘license’ as the Microdesk.Utiity.UnitTest.dll library: do-what-you-want-but-don’t-hold-me-liable-for-it (which is basically the BSD license AFAIK).
I didn’t intentionally avoid showing the IPersistentObject interface, the implementation of the GuidIdentityPersistentBase, or any other of the classes/interfaces in the assembly (there are more including an implmentation of ISpecification
that provides easy implementations of the Specification pattern).
You actually point out that I failed to provide the code download for this screencast (a completely accidental oversight) so I will post that to the Autumn of Agile site in the next day or so.
The main reason that I’m not (as of now) focused on releasing the library is that I expect that I am adding to it on a frequent basis as my needs grow and so its somewhat unstable (in re: its content, not in re: the quality of its codebase 🙂 ).
[…] for the delay, but I’m happy to announce that as of now the code samples for both PART A and PART B of the Iteration 01 installments for the Autumn of Agile screencasts have now been […]
Can you give any insight as to what life would be like, if I decided to migrate away from Guids as my IDs to Ints? (In the context of this application of course.)
[…] Comments Lee Carter on Autumn of Agile Iteration 01 Part D Screencast is AvailableRyan on Autumn of Agile: Iteration 1 Part A screencast is availablemynkow on Autumn of Agile Iteration 01 – Part C Screencast is now AvailableYitzchok on Horn Project: […]
Great question. I started to answer in the comments and then realized that the issue deserved a new post that explained it in some detail. Here you go…