Archive for April, 2010
PRISM event aggregator: more leaky than it seems
Gotcha of the day: the Prism framework for WPF and Silverlight offers an application-wide event bus system that allows you to publish and subscribe events without having to have a reference to the publisher. This is hugely useful for decoupling parts of an application that should not hold references on one each other just because you want to be notified that something is going on.
By default, when you subscribe to an event, you pass only a WeakReference of yourself (that’s you, the subscriber object); the subscriber will still be garbage-collected when it becomes unreachable. There is however an option to keep the subscriber alive as long as it does not explicitly detach itself from the event subscription. This behavior is useful when listening to the event is the sole purpose of something. Per documentation, the weak reference is the default. What actually happens however is that you get the second behavior, and instances of the subscriber classes leak out into the application. Which is not a huge problem until you dynamically create and abandon these. Which is what I do.
However, there is a bug in the CompositePresentationEvent class. In the Subscribe method, there is a fork whether a filter predicate has been set or not; in the branch where no filter is set, the keepSubscriberReferenceAlive parameter (which controls if the subscriber is kept alive by the subscription) is not applied correctly. Here’s the culprit:
if (filter != null)
{
filterReference = new DelegateReference(filter, keepSubscriberReferenceAlive);
}
else
{
filterReference = new DelegateReference(new Predicate<TPayload>(delegate { return true; }), true);
}
See the “true”? Yep. Should be “keepSubscriberReferenceAlive”.
The problem is described in PRISM’s defect tracking; since it’s low priority, it seems unlikely it’s going to be fixed. So you can either correct and compile your own version, or use the overload of the method that allows you to specify a filter. What I had to find out is that you cannot use an anonymous method in the form of a lambda expression like “(filter) => true” as a filter: since this is a private method behind the scenes, you get a MethodAccessException. You need to specify a non-anonymous method.
EventAggregator.GetEvent<MyEvent>().Subscribe(MyHandler, ThreadOption.PublisherThread, false, NullEventSubscriptionFilter );
public bool NullEventSubscriptionFilter<T>( T param )
{
return true;
}
Which is what I’m going to do now.
NUnit for Silverlight updated: NUnit 2.5.5, Silverlight 4
Some while ago, I’ve ported NUnit to Silverlight; that post has been a follow-up to to Jeff Wilcox’s description of how to write unit tests instead of the standard MSTest syntax.
Here’s an update for the ported version of NUnit for version 2.5.5, and for both Silverlight 3 and Silverlight 4.
To create a Silverlight unit test project that uses NUnit, follow these steps:
- Download and extract the binaries, or download the source code and build the assemblies on your computer
- Create a new Silverlight unit test project using the Silverlight unit testing framework (and of course if you don’t have it installed, you should do that by now).
- Reference the three assemblies from the NUnit for Silverlight project.
- In the App.xaml.cs file, register the NUnit unit test metadata provider. This is done in the StartUp event handler for the application, before the test page is created:
private void Application_Startup( object sender, StartupEventArgs e ) { UnitTestSystem.RegisterUnitTestProvider( new Microsoft.Silverlight.Testing.UnitTesting.Metadata.NUnit.NUnitProvider() ); RootVisual = UnitTestSystem.CreateTestPage(); }
UPDATE
- 11-May-2010: Fixed a problem with the Silverlight 4 port; an assembly from the Silverlight 3 testing framework had been referenced.
- 11-June-2010: Updated the NUnit port, please see NUnit for Silverlight: Now with data driven tests
- 01-Dec-2010: Moved the project to Google code, updated to NUnit version 2.5.8.
Download
Please download from nunit-silverlight on Google Code.
Estimate this!
Randy Rice wrote an insightful post in his blog, “Dirty Little Secrets About Software Test Estimation”. Usually I don’t like just linking to stuff other people write (feels cheap…), but this time I think it’s fair game, because I would have said exactly the same anyway, or most of it, though less elegantly I suppose. Thanks to Randy I can save me that effort now.
While I’m lazily linking stuff, do you already know Rands In Repose? I learn something new every time I go there.
Peer pressure
About yesterday’s post: I continued to discuss making successful sprints objectives for sprint teams, and someone gave me a good point against doing this. Not only would it mean putting the sprint team under a lot of pressure and it would probably make them commit to less user stories – that I thought about myself – but more importantly, it would also put a lot of pressure on the people who accept or reject a sprint: the product owner and other reviewers. This can quickly become very tricky when these people have conflicting interests or close relationships with people in the sprint teams.
My goals, your goals, our goals
Many companies do it: variable pay, or bonus payouts based on individual performance. It’s easy if you work in sales: The more you sell, the higher your bonus. It’s trickier with us developers and testers. We’re too far away from the money, we need personalized goals. Could be getting a certification, or reading a book. Could be team work related. The softer the goals become the harder they are to rate. And what good are goals that basically only tell you to do your everyday job?
So what’s the goal of having goals? You need a specific task or project getting done. Or you want to develop a specific skill. Or, you aim for personal fulfillment. Motivation. It might depend on many variables. Do you/your manager need to delegate a bigger task? How much time do you have to fulfill the goals? Is it a bonus plan? Is it variable pay, i.e. considered part of the “normal” salary? Do you have team goals?
I’m not going to cover good or bad goals in general here. Depending on your situation and company culture your goal and performance processes probably differ a lot. My question at hand is: How much sense does it make to have goals in an agile (Scrum) team? What kind of goals would you set? Would you still have individual goals? And most importantly: would it be a bad idea to make the success of the team’s sprints a goal for all team members?
I thought about this a lot and a fellow team lead has a very strong opinion about this. I can’t help but agree with many of his points. What’s the main objective of a sprint team? To deliver. To get their sprints done and signed off. By definition, they work as an independent unit while on a sprint, and all team members are equally responsible. If they fail, the whole team fails.
Of course you could still have individual goals, but the strict “do not interfere with sprints” rule applies and it’s a walk on a razor’s edge when a line manager from outside the team requests specific work from a sprint team member. If you don’t put time aside or rule that goals need to be worked on private time (a big no-no in my book), it’s nearly impossible not to interfere with the sprint team’s work if you’re handing out extra goals. So why not giving them all the same goal: successfully finish your sprints. Pass or fail. (You could still have individual development goals on the side, weighted less, if you’re extra careful (see above).)
I talked to some colleagues and they immediately said “No, bad idea. What if the sprint fails, but due to problems from the outside?” Well, in theory that should never happen. If the team cannot successfully finish their sprint due to influences from outside the team, it’s not their fault. Either their Scrum master failed to help, or the sprint needs to be cancelled, but not “failed”. Is it fear of being given the full responsibility? What’s the consequence of a failed sprint – if there isn’t any but “we’ll just start over”? Or is it that they’re scared one team member might be responsible for the failure of the sprint, and since they all have the same goal they would suffer, too? Don’t they trust their line manager, i.e. reviewer, to see this all and take it into consideration come review day? I believe it’s probably a mixture of all of it, the hurdles for successfully passing a sprint are quite high in our company (and rightfully so).
So my question remains, does anyone have a qualified, logic reason to vote against having a shared team goal for members of Scrum sprint teams that is based on the success of their sprints within the bonus/performance review period? Because I don’t really, and yes, I’ve been working within sprint teams as well.
Infinite in faculties
What a piece of work is a man, how noble in reason, how infinite in faculties, in form and moving how express and admirable, in action how like an angel, in apprehension how like a god! the beauty of the world, the paragon of animals—and yet, to me, what is this quintessence of dust?
Good question, Mr Shakespeare. In the end, man’s apprehension only goes so far, and that’s where we testers come in.
Everyone who’s ever worked with a more-than-trivial setup, that the very old piece of wisdom “Never change a running system” still applies, maybe even more so today, with all the interconnectivity and layers of complexity our systems have. Changing a live production environment is a challenge, moving it is a nightmare, moving it without moving the physical machines even more so.
You need a very detailed plan that covers all the interconnected servers, services, firewalls, databases. You need a contingency plan. You need to inform your customers about the downtime. You need test scripts. And you need testers. And, of course it all happens on the weekend and has to work perfectly on Monday.
It’s funny how time works differently when you migrate systems, it’s almost like it happens in a parallel universe where a minute is worth two of yours. As a tester, you can do nothing while you wait for the new environment to come online so you can do your job. There’s always one more port that needs to be rerouted or a file transfer that needs to finish. It can be very frustrating when “We might need you on the weekend, be prepared” becomes certainty – but not before the end of the week. You have all your scripts ready at hand, you join all the prep calls, but all you can do is wait.
It doesn’t matter if in the end all works out fine – everyone feels wrecked when it’s over. If your system has good testability and automated tests you can at least tell how confident you are that the new “prod” will behave itself. But if you don’t, for example because you do not get all the time you want for running your complete suite, as a tester you can only point out what you have verified working and what you don’t know – you are a walking disclaimer. Sure, you’re not the one making the final Go call. But as tester, you love facts, you want things to work – and you only trust them when you had the chance to try them.
So how do you prevent this situation? Have contingency plans not only for project failure, but also for the case that you don’t get the chance to run all your tests. Sometimes a release cannot be postponed, no matter how “disclaimatory” you get. Organize your planned efforts in tiers. “This is what I want to test. If I lose two days, I’ll only test this and ask Bob and Jane to help, although they don’t know the system so well. In the worst case, I’ll test these critical cases.” Really, have this ready before you start hearing about delays. Because you will hear about delays.
And: communicate early. Tell your people they will have to work on Saturday. Tell them it’s going to be painful. Don’t freak them out but give them what you have and why this is necessary. Get a commitment from the guys on other teams you plan on asking to help, get their line manager on board. If your IT crowd manages to pull a miracle and give you your testing time during the week after all, or the project is canceled, you can still roll back. It’s better to expect having to work late and be then be told it won’t be necessary than to speculate every day after each update call. And this is true no matter whether your people have a great “duty & responsibility” attitude or not, especially for testers who are typically lovers of facts and information.
Last but not least, be prepared yourself. Make sure every potential tester can access your issue tracking tool, the VPN, scripts, conferencing tools etc. on the weekend. Include non-techie instructions in your scripts for helpers from other departments. Have a single point of contact where executed scripts are sent. Keep track of the progress and any defects for the case the CTO calls from the airport between transfers, asking how’s it going.
And very last, don’t panic. Life’s too short.
Signing in
Posted by Tobias in Uncategorized on April 18, 2010
Hi, I’m the new guy. Christian, kind and social as he is, invited me to join blogs – and here I am. I won’t bore you with the details, and just say that I’m going to be – and proudly – “Tobias the QA guy”, as that’s what I do. We thought some posts about testing couldn’t scare away too many of Christian’s readers. Glad to be here.
Detecting a changed DataContext
A colleague showed me a great and simple solution for a problem: finding out when the DataContext of a Silverlight control changes.
Let’s say a details form is bound against a Dog object. To the left of the form there is a list of dogs, when the user clicks a Widget in the list, the DataContext of the form is set.
The form contains a control for picking the name of the dog. This is a special control: when the user has modified the dog name, its background is set to yellow.
The when writing this control is that you can monitor changes on the Text property, and then turn the control’s background to yellow when it changes. The challenge is how to reset the background color. We need to determine if a change comes from manipulating the value, or from changing the dog in the list, i.e. the form’s DataContext.
It’s not possible to directly watch the DataContext; there is no event for that.
Here’s the solution that my colleague found: declare a new DependencyProperty that does nothing more than execute a PropertyChangedCallback when its value changes. And then, bind this property directly against the control’s DataContext. OK, if someone assigns a value or a binding or a value to that property in XAML code, the mechanism breaks, but that’s what we’ve got comments for.
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
namespace GreenIcicle.DetectDataContextChange
{
public class DogNameTextBox : Control
{
// Constructor
public DogNameTextBox()
{
// Bind a DependencyProperty against
// the DataContecxt of the control.
// Since no path is specified, the DataContext
// itself is bound.
SetBinding(DataContextWatcherProperty, new Binding());
}
// In this method, add the payload logic that is called
// whenever the DataContext of the control changes.
protected virtual void ResetControlState()
{
// Reset the control's state
}
// Dependency property that is bound against the DataContext.
// When its value (i.e. the control's DataContext) changes,
// call DataContextWatcher_Changed.
public static DependencyProperty DataContextWatcherProperty = DependencyProperty.Register(
"DataContextWatcher",
typeof(object),
typeof(DogNameTextBox),
new PropertyMetadata(DataContextWatcher_Changed));
// Called when the control's DataContext changes.
public static void DataContextWatcher_Changed(
DependencyObject sender,
DependencyPropertyChangedEventArgs args)
{
// Call ResetControlState on the control of which
// the DataContext has been changed.
DogNameTextBox senderControl = sender as DogNameTextBox;
if (senderControl != null)
{
senderControl.ResetControlState();
}
}
}
}
Thanks to Andreas/Raphael for finding this out!
What’s worse than a broken build?
Posted by Christian in Uncategorized on April 14, 2010
… or, in general, the worst thing that can happen in a software shop?
A broken coffee machine.
Seen here, today.
Visual Studio 2010 Express – No tests, please.
So Visual Studio 2010 has been released today. I recognize that .NET 4 is a great step forward, and Silverlight 4 just sounds sweet. But for people who are not provided with licenses by their employer, there’s quite a drawback.
The Standard edition has gone away. The previously cheapest edition of Visual Studio is no longer offered. With Visual Studio 2010, the lowest possible license is the Professional Edition which comes for $550 with a basic MSDN subscription for one year and $1,200 for a license with one year of a full MSDN subscription. Now if you’re an enthusiast or self-employed on the lower end of the food chain, this might be hefty price tag – and a significant increase compared to Visual Studio 2008 Standard (approx $280).
So at a first glance, moving away from the full versions of Visual Studio to the Express versions might sound tempting. You can have multiple Express Editions on the same machine (e.g. C# for Windows Services and Web Edition for ASP.NET and Silverlight), and the license does not prohibit commercial use.
However, there is one drawback that sounds like a massive deal breaker to me. Running Unit tests with Visual Studio 2010 is not (easily) possible.
Firstly, the integrated MSTest feature does not seem to be included. It’s not in the menu, and the ASP.NET MVC2 template comes without the test project it normally includes. Well, I could live with that, as I am a confession NUnit aficionado.
But: in Express Edition, you cannot attach the debugger to NUnit. The usual workflow is: start NUnit, attach the debugger to the NUnit process, debug your test. In Express Edition, the ability to attach the debugger to an exisiting process has been removed. And as plug-ins don’t work due to licensing restrictions in Express Edition, it’s not possible to retrofit the ability to run tests. (Visual NUnit for example won’t install.)
Steve Dunns has published a workaround for NUnit; it works by turning the unit test project into a command line application and bootstrap NUnit. That’s a nice trick and not the opposite of elegant, but far from ideal.
I’m not one who says everything should be free. Microsoft do not claim to offer a free full-blown development environment; that’s OK. But from all things that you can leave out: why does it have to be the all abilities to run unit tests? That seems like a strange signal towards the importance of quality.
-
You are currently browsing the archives for April, 2010
Authors
-
