Today MSDN Live was visiting Bergen, and I must say it was a very interesting day all together. My day looked like this:
- Introduction to Silverlight 2 by Gøran Hansen
Basic introduction on how Silverlight works, what the possibilities and limitations are of the .Net 3.5 Framework subset that is used by Silverlight. How Silverlight communicates to the hosting server and the cross site communication possibilities. This combined with some clear XAML code examples.
- ASP.NET Dynamic Data by Gøran Hansen
This is great! Well when you have to build a data entry web application than this is a live saver. Nobody really wants to create all the different pages to populate and manage database tables. ASP.NET Dynamic Data will do this for you, and the great thing about it is that you can use templates to customize the generated pages. A nice fact is this is also supposed to be made available for ASP.MVC.
- Want SOA? Throw out your web services by Anders Norås
Hehe SOA without Web Services, Anders argues that using web services are still creating a too tight coupling between the various systems. He instead suggests using a service bus where messages / events are being fired and clients can register to these messages / events. He shown examples using NServiceBus. I guess I got some more reading and playing to do :)
- Internet Explorer 8 for Developers by Anders Norås
This for me was the least interesting part of the day, which has nothing to do with the presentation, but more with the actual topic. I lost interest in the different browsers quite some time ago. One cool thing was to hear that Microsoft IE 8 now is actually complaint and will not be as forgiven anymore, possible breaking many internet pages. There is of course an IE 7 mode.
Scott also just wrote a post about comparing Microsoft IE8 and Google Chrome: http://www.hanselman.com/blog/MicrosoftIE8AndGoogleChromeProcessesAreTheNewThreads.aspx
- Application Development in WPF by Gøran Hansen
This was a very interesting presentation, which involved lots of code, code is good :) the talk was targeted using WPF, but it could have been about any programming language or framework. The main message was to create lousy coupled code, program to interfaces and separation of concerns. This all sounds very true to me, so it was enjoyable to listen too ;) Than in combination with WPF Gøran showed how to disconnect the GUI front end XAML from the code using it. And he went into how to test the code that would be using the XAML.
Afterwards we discussed a little bit the ability (or disability) to actually test the XAML file, I have some ideas about that and will try to create a small project around that and will post it in my blog.
Gøran Hansen - http://blog.goeran.no/
Anders Norås - http://andersnoras.com/blogs/anoras/default.aspx
Posts
7 comments:
Hi Mark
This is going to be a short comment. I’m glad you did enjoy MSDN Live yesterday and thanks for the good feedback here on your blog! I agree with you that code is good, and if I could I would probably throw out all the “slideware” from presentations. I’m a coder at heart I guess, hehe.
You people in Bergen was a great audience that showed lots of engagement during my presentations. And you even blog about it afterwards! Lots of kudos to you guys and gals! This is what keeps me going!
As you said, we had an interesting discussion after my presentation, and I want us to continue this discussion here in the blog sphere. I would love to read more about your ideas regarding testing the actual VIEW (XAML file). Maybe this blog post can fuel your ideas: http://www.jeff.wilcox.name/2008/03/31/silverlight2-unit-testing/.
By the way, I’ve added your RSS feed into my aggregator.
Cheers
Gøran
Hi Gøran,
Interesting link! I hope to be able to do it in a different way, not using the browser, and possibly independently from the Silverlight or WPF choice. I'll definitely blog about it if I come up with something.
You're in my Google Reader list too ;)
-Mark
Hi Mark,
In WPF Microsoft introduced the UI Automation APIs. This API is also included in Silverlight. The API gives the hooks needed to drive the UI, for things such as screen readers or other accessibility software.
One of the reasons Microsoft is calling this UI automation (and not accessibility) is that the same API can be used for other things, such as driving the UI in automated tests.
One popular framework that works well with WPF and Silverlight is the White testing framework created by the guys at ToughtWorks.
http://www.codeplex.com/white
The Silverlight testing framework referenced by Gøran is a little bit different. It can be used to do UI testing, but you have to give Silverlight access to the internal members of your form. It also gets hard to really test the UI using the Silverlight testing frameworks as there are things that is hart to mimic. You cannot invoke a click programmatic, but you can call the click event handler... But it's still not the same thing. Say you're using a command pattern for buttons hand have no click event handler. In that case the only way to actually click the button is through the UI Automation API.
Cheers,
Jonas Follesø
http://jonas.follesoe.no
Jonas,
Thanks for the links and information, I'll look into those solutions before trying to create something myself ;)
The general idea is that as a Developer I want to create a simple form just to have the needed functionality. Than I send this XAML file to the designers and when I get it back I want to be able to verify that all functionality is still there and working.
-Mark
Great input Jonas. Yes, checking out White should be worthwhile; you probably will find some inspiration there.
White works perfect when doing functional testing from the end user perspective. In Presentation Model all the interaction logic is implemented in a separate class with no dependency to UI frameworks. So this is easy to test, and here we don’t need White. But testing that the View (XAML) is behaving correctly indirectly also verifies that the View (XAML) is implemented correctly on top of the Presentation Model. But testing both with White and test unit test is like shooting a bird with a canon.
To test the View (XAML) it’s self and that it’s synchronizing correctly with the PM, is possible. You could for instance traverse the logical three of the UI composition and check if there are set up any bindings to a PM, and validate that they binds to properties that exist on the PM. What tends to happen when using this pattern is that a developer changes a property on the PM, and then breaks the synchronization between the View and the PM. This is usually not detected before runtime, and when someone is using the application and detects the misbehavior of the app. So what we need is a tool that can detect this, and I think that is something like this you are thinking about Mark?
Gøran
That is exactly what I am thinking about. XAML behaviour testing.
-Mark
And that's exactly what White lets you do - verify that the XAML is implemented correctly ontop of the PM, and that you get the expected behaviour.
However, one of the things you suggest is actually quite interesting. Allmost like a static XAML validator that could report any unbound or missbound XAML elements, or buttons that don't have an event handler or a command, to give you some idea if the designer screwed up.
That beeing said, I think it will take some time before we're at a level where you can send off an XAML file to a design agency and get back something usefull. The problem is for one that many apps are missing design time dummy data. I know Microsoft is working on tools making this easier, and patterns like PM with mock service implementations also help alot.
But even if you can't send your entire XAML file to a design aganecy, starting out small by having them do Adobe Illustrator screens, illustrations, icons and logos goes a long way, as these can be imported easaly as XAML assets.
I also think that we in the future will see sites and communities like with WPF themes you can drop in. http://www.nukeation.com/ is one example of such a comapany.
Post a Comment