The Enumerable<T>.Distinct method is a very useful helper; it was definitely requited to complete the LINQ to SQL offering (to support TSQL’s DISTINCT), and the corresponding support in LINQ to objects is very nice indeed. However, since DISTINCT runs on primitives in the DB, and objects may be a bit more complex than a simple byte-to-byte comparison – the plot might thicken.
This test passes easily.
[Test]
public void DistinctOnPrimitives()
{
var arr = new[] {1, 1, 2};
Assert.AreEqual(2, arr.Distinct().Count());
}
But this one fails:
public class A { public int B { get; set; } }
[Test]
public void NaiveDistinctOnObjects()
{
var arr = new[] { new A { B = 1 }, new A { B = 1 }, new A { B = 2 } };
Assert.AreEqual(2, arr.Distinct().Count());
}
We could override the Equals and GetHashCode to make the test pass.
Btw, have ReSharper do it for you. Click “Generate” on the type and select “Equality Members”.
And BAM:
public class A
{
public int B { get; set; }
public bool Equals(A other)
{
if (ReferenceEquals(null, other)) return false;
if (ReferenceEquals(this, other)) return true;
return other.B == B;
}
public override bool Equals(object obj)
{
if (ReferenceEquals(null, obj)) return false;
if (ReferenceEquals(this, obj)) return true;
if (obj.GetType() != typeof (A)) return false;
return Equals((A) obj);
}
public override int GetHashCode()
{
return B;
}
}
And that’s one way to make the previous test pass. But what if we don’t want to implement equality? What if the object should normally be compared by ref, and not by value? What if the equality grammar for this object is not what’s required for this specific Distinction? What if we cannot change the class?
A lovely override for Distinct accepts an IEqualityComparer<T> parameter. That’s a whole new type. So if we need to send an instance of a comparer, we need to both implement the comparison and instantiate it.
(Note that I’ve omitted a lot of required checks (nulls) for brevity)
public class AEqualityComparer : IEqualityComparer<Tests.A>
{
public bool Equals(Tests.A x, Tests.A y)
{
return x.B == y.B;
}
public int GetHashCode(Tests.A obj)
{
return obj.B;
}
}
And now we can have this passing test:
[Test]
public void EqualityComparerDistinctOnObjects()
{
var arr = new[] { new A { B = 1 }, new A { B = 1 }, new A { B = 2 } };
Assert.AreEqual(2, arr.Distinct(new AEqualityComparer()).Count());
}
But I have a distinct feeling (pun intended. Send your complaints here) that real production logic would call this Distinct(new AEqualityComparer()) a lot, and the instantiation is totally useless there.
<SingletonsAhead>
Fortunately, there’s a pattern to help us with that issue – we can have a single instance of the comparer to be used every call. Since our comparer object is stateless, and is basically just an encapsulation of unchanging comparison logic – I have no problems actually using this pattern here.
I’m using a cool little Singleton<T> helper class which looks like this:
public abstract class Singleton<T>
{
public static T Instance { get { return Nested.InnerInstance; } }
private static class Nested
{
public static T InnerInstance { get; private set; }
static Nested()
{
InnerInstance = (T)Activator.CreateInstance(typeof (T), true);
}
}
}
(It’s lockless and lazy, so it’s a good enough implementation).
Now our comparer class looks like this:
public class AEqualityComparer : Singleton<AEqualityComparer>, IEqualityComparer<Tests.A>
{
protected AEqualityComparer() {}
public bool Equals(Tests.A x, Tests.A y)
{
return x.B == y.B;
}
public int GetHashCode(Tests.A obj)
{
return obj.B;
}
}
And the passing tests looks like this:
[Test]
public void SingletonEqualityComparerDistinctOnObjects()
{
var arr = new[] { new A { B = 1 }, new A { B = 1 }, new A { B = 2 } };
Assert.AreEqual(2, arr.Distinct(AEqualityComparer.Instance).Count());
}
Which is, in my mind, HORRIBLE.
The actual comparison is twice removed from where it’s executed, and I ha to create a new class for this pointless exercise.
</SingletonsAhead>
A much much cooler method to do this would be like so:
[Test]
public void DistinctByPropertyOnObjects()
{
var arr = new[] { new A { B = 1 }, new A { B = 1 }, new A { B = 2 } };
Assert.AreEqual(2, arr.DistinctByX(x => x.B).Count());
}
Or, if we have more than one property to compare – like this:
[Test]
public void DistinctByPropertyOnMoreComplexObjects()
{
var arr = new[] { new A { B = 1 }, new A { B = 1 }, new A { B = 2 } };
Assert.AreEqual(2, arr.DistinctByX(x => x.B, x => x.C).Count());
}
So how do we go about implementing that? Long story short – here’s the code for the extension method:
public static class EnumerableOfTExtenstions
{
public static IEnumerable<T> DistinctByX<T>(this IEnumerable<T> source,
params Func<T, object>[] membersToCompare)
{
return source.Distinct(AdHocComparer<T>.For(membersToCompare));
}
private class AdHocComparer<T> : IEqualityComparer<T>
{
private readonly Func<T, object>[] _MembersToCompare;
private AdHocComparer(Func<T, object>[] membersToCompare)
{
_MembersToCompare = membersToCompare;
}
public static IEqualityComparer<T> For(Func<T, object>[] membersToCompare)
{
return new AdHocComparer<T>(membersToCompare);
}
public bool Equals(T x, T y)
{
return _MembersToCompare.All(c => c(x).Equals(c(y)));
}
public int GetHashCode(T obj)
{
return _MembersToCompare.Aggregate(0, (agg, c) => agg ^ c(obj).GetHashCode());
}
}
}
Now, it’s not perfect by any means: we’re still instantiating objects per comparison (need to cache those somehow, and use an efficient key for that cache), we have an additional overhead from the delegate access to the properties, we’re still not checking for nulls and all kinds of funky cases (need to write some more code), but by golly, that’s EXPRESSIVE, ain’t it?
So after having my fun with the extension method – I’ve reverted my code to use the singleton-based comparer. It felt like the grownup thing to do. Sorry for the anti-climax.
Yesterday at the Alt.Net tools night I gave a short talk about how to get started with NHibernate. “Getting started” means we’re talking about Greenfield project, heavily favoring Conventions (and automappings) over Configuration, and not having to mess with existing, untouchable codebase or DB schema.
The weird part was sitting there, after having used NH, a 5 year-old project, for about a week, and across the table sat Ayende, one of the main contributors to NH (and author of NHProf). Most of the time he wasn’t throwing heavy items at me, so I called that session a success.
The goal of the demo was to make this integration test pass:
[Test]
public void SaveAndLoadEntity_AssertSavedValueIsSame()
{
// Arrange
var instance = new Saver();
var entity = new MyEntity();
entity.Val = 34;
instance.Save(entity);
// Act
var retVal = instance.Load();
// Assert
Assert.AreEqual(34, retVal.Val);
}
(The test was created in exactly three seconds using QuickUnit. Try it out.)
I won’t re-run all the “run test, fix error” iterations here, just review the concepts and show the outcome.
DB config Issues:
- We want the test to pass as easily as possible, have no side effects, and require minimal setup costs – so we’ve used SQLite in-memory DB, using System.Data.Sqlite (free). The single DLL is the ADO.NET adapter AND the actual DB.
- Standard configuration of in-memory SQLite kills the DB after every session closes, so we needed a different connection string.
- Since we’re creating a new DB every test – we need to create the DB schema every time, using the SchemaExport tool. (More)
- Make sure the reference to System.Data.Sqlite has the “Copy local = true” flag (as it is not a completely managed dll, and does not default to true).
- Also watch out for 64bit issues and FW4.0 issues with System.Data.Sqlite.
Mapping issues:
- We desperately want to use FluentNHibernates’ automapping, so we provide an assembly to scan for entities, and a minimal adaptation of the DefaultAutomappingConfiguration object (I’ve chose to use attributes to mark persisted types. Inheritance can do just the same).
- Every entity needs a primary key in RDBMS. So we’ve added the Id property on MyEntity.
- NH wants to provide you with lazy loading for your data, so it needs to override your properties (creating dynamic proxies at runtime), so you need to make them virtual (and add a reference to the NHibernate.ByteCode.Castle assembly)
NHibernate usage issues:
- An ISession object is lightweight (and can be thought of as “Cache Scope”). Create one when it’s a logical thing to do.
- An ISessionFactory object is VERY heavyweight. Create and save it.
- Always open (and commit) a transaction (saving OR loading).
- The three main query mechanisms for NH are HQL, ICriteria and Linq2NH. I find it silly that in 2010 I won’t use linq to express my queries, so (for NH 2.1.2 only) you need to add the NHibernate.Linq.dll. NH v3.0 incorporated that syntax in the core.
Test issues:
- Make sure you add the required references above to the tests project, so that NHibernate can, at runtime, use all those assemblies required.
1: using System;
2: using FluentNHibernate.Automapping;
3: using FluentNHibernate.Cfg;
4: using FluentNHibernate.Cfg.Db;
5: using NHibernate;
6: using System.Linq;
7: using NHibernate.Cfg;
8: using NHibernate.Linq;
9: using NHibernate.Tool.hbm2ddl;
10:
11: namespace NHStart
12: {
13: public class Saver
14: {
15: public void Save(MyEntity entity)
16: {
17: using (var session = GetSession())
18: using(var tx = session.BeginTransaction())
19: {
20: session.Save(entity);
21:
22: tx.Commit();
23: }
24: }
25:
26: private ISession GetSession()
27: {
28: var sessionFactory = Factory;
29: return sessionFactory.OpenSession();
30: }
31:
32: protected ISessionFactory _Factory;
33: protected ISessionFactory Factory
34: {
35: get
36: {
37: if (_Factory == null)
38: {
39: Configuration config = null;
40:
41: _Factory =
42: Fluently
43: .Configure()
44: .Database(SQLiteConfiguration.Standard.ConnectionString(x => x.Is("Data Source=:memory:;Version=3;New=True;Pooling=True;Max Pool Size=1")))
45: .Mappings(x=>x.AutoMappings.Add(AutoMap
46: .Assemblies(new MyAutomappingConfiguration(), typeof(MyEntity).Assembly)))
47: .ExposeConfiguration(x=>config = x)
48: .BuildSessionFactory();
49:
50: using (var session = _Factory.OpenSession())
51: {
52: new SchemaExport(config).Execute(false, true, false, session.Connection, Console.Out);
53: }
54:
55: }
56: return _Factory;
57: }
58: }
59:
60: public MyEntity Load()
61: {
62: using (var session = GetSession())
63: using (var tx = session.BeginTransaction())
64: {
65: var item = session
66: .Linq<MyEntity>()
67: .First();
68:
69: tx.Commit();
70:
71: return item;
72: }
73: }
74: }
75:
76: public class MyAutomappingConfiguration : DefaultAutomappingConfiguration
77: {
78: public override bool ShouldMap(Type type)
79: {
80: return type.GetCustomAttributes(true).OfType<PersistedAttribute>().Any();
81: }
82: }
83:
84: [Persisted]
85: public class MyEntity
86: {
87: public virtual int Id { get; set; }
88: public virtual int Val { get; set; }
89: public virtual string Val2 { get; set; }
90: }
91:
92: public class PersistedAttribute : Attribute {}
93: }
I’ve even added line count to show how 93 lines of code can create a (simple) persistence layer. It was fun.
I feel dirty whenever I use XOR in my code. Then I’m proud of myself and suppress any previous feelings which may indicate that I did something wrong.
Anyway, when WPFing and messing with visibility of items – the BooleanToVisibilityConverter is a very handy tool. However, binding to a bool property means that you need the bool mean the same as the visibility, i.e. true for visible. If you need the opposite – you need to create an opposite property on the VM to bind to, or write an opposite converter.
No more.
1: public class BoolToVisConverter : IValueConverter
2: {
3: public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
4: {
5: return (bool)value ^ (parameter == null ? false : !bool.Parse((string)parameter)) ? Visibility.Visible : Visibility.Collapsed;
6: }
7: …
8: }
Using a ConverterParameter in your binding expression you can just specify to negate the return value of the bound property.
Usage in XAML:
Visibility="{Binding IsInvalidState, Converter={StaticResource BoolToVisConverter}, ConverterParameter=false}"
Just in case someone encounters this – WPF4 RC version has a small bug (fixed in the RTM) which has the unfortunate consequence of throwing an exception on a WPF thread (with no user code in the way to handle it), and crashing the application.
Below are the three version of the TextBoxView.ClearLineVisual code (which cause the exception), from ver3, ver4RC and ver4RTM…
private void ClearLineVisual(int lineIndex)
{
if (((this._viewportLineVisuals != null) && (lineIndex >= this._viewportLineVisualsIndex)) && (lineIndex < (this._viewportLineVisualsIndex + this._viewportLineVisuals.Count)))
{
this._viewportLineVisuals[lineIndex - this._viewportLineVisualsIndex] = null;
}
}private void ClearLineVisual(int lineIndex)
{
if (((this._viewportLineVisuals != null) && (lineIndex >= this._viewportLineVisualsIndex)) && (lineIndex < (this._viewportLineVisualsIndex + this._viewportLineVisuals.Count)))
{
this._viewportLineVisuals[lineIndex - this._viewportLineVisualsIndex].DiscardOnArrange = true;
this._viewportLineVisuals[lineIndex - this._viewportLineVisualsIndex] = null;
}
}
private void ClearLineVisual(int lineIndex)
{
if (((this._viewportLineVisuals != null) && (lineIndex >= this._viewportLineVisualsIndex)) && ((lineIndex < (this._viewportLineVisualsIndex + this._viewportLineVisuals.Count)) && (this._viewportLineVisuals[lineIndex - this._viewportLineVisualsIndex] != null)))
{
this._viewportLineVisuals[lineIndex - this._viewportLineVisualsIndex].DiscardOnArrange = true;
this._viewportLineVisuals[lineIndex - this._viewportLineVisualsIndex] = null;
}
}
Mark wrote a post about unit tests structure, and the need for similar tests to look the same.
Good points there. I like my tests to show their essence in a very visible way – the concrete values for the scenario and the assertion are more often than not just the primitives which vary between test case to another.
If you read the subject of this post you already know where I’m going with this: I really like row tests’ ability to concisely describe the variance between cases. So much so that I’d advocate using [RowTest] even if you have a couple of test cases (like in Mark’s example), to make the tests more readable.
As a side note – QuickUnit doesn’t support generating your tests in such a data driven manner yet, but we’ll get to it shortly.
I’ve read a couple of things that got me smiling. I am a bit tipsy, so smiling may be the manifestation of a chemical imbalance or just a nervous tick.
Karl Seguin’s post:
Ultimately, the most important thing is that you have automated tests which aren't a nightmare to setup, maintain or run. Integration tests have more dependency and thus are more fragile, but can be an efficient way to verify correctness.
Ayende’s post:
TDD fanatic corner: I don’t really care about testable code, I care about tested code. If I have a regression suite, that is just what i need.
Excuse the subject line. I wasn’t feeling creative. This post is in response to Derick’s post.
Derick asks if he should program his stubs with exact arguments per expected method call, and ends with “I know the answer is ‘it depends’”, but me - I’m a man of extremes. I don’t think it depends, and you should probably never use it (specifications), or, if you do “have to use it” – consider it a code smell for the tested code.
To me it’s like having more than one assert in you test: what happens if the method is called with “2” and not “1”? The test will fail? The stub will crash? Or is it that the real code will fail? If it is the latter – indeed you need to make sure the value is “1” and nothing else, in the scenario you test.
And you know how we do that, right?
Exactly – add another test. Add a test which checks that logic which renders that “1” argument works properly. If it really must be “1” – than we’re talking about functional requirement, and not an implementation detail, so that logic should be properly tested, and probably publicly exposed. If it doesn’t really have to be “1” there – than just don’t check it. Let the test fail on the real assertion.
And if we’re on that subject – don’t write tests with a mock object which expects a method to be “Called with exact arguments”. IT SMELLS! Separate the argument generation for the actual invocation and test them. Don’t write the simple test and disband the required refactoring – do the simple refactoring and then write the simpler test.
Yes, well… yes.
After a fascinating couple of weeks on VS2010RC – I’m going back, sir.
Simply put – performance is shite. Yes, I’m using Resharper, yes, I have a lot of XAML, and yes WiX wasn’t always very kind to me (general purpose rant), but if I actually feel that everything takes longer, and VS hangs, and takes heap loads of memory, and running my tests take longer, and I need to always think about backwards compatibility, and all the available tools are beta-ish – than I think I can manage to wait a couple of months more for the eco-system to stabilize.
Farewell, 2010RC. We hardly knew you.
(But the zoom in the edit does kick ass)
In QuickUnit we develop a Visual Studio addin which allows developers to easily create quality unit tests. It’s a rather complicated, highly extensible, code-analysis and code-generation, .net application, with a rather complex UI layer (but with a simple UX). We use WPF (on MVVM) for the UI infrastructure, and make very heavy use of viewmodel objects, data bound to data templates.
We’ve encountered a scenario where our memory consumption started growing, after every action which basically only re-rendered the UI. ProcessExplorer was kind enough to show us that the gen2 heap was growing steadily, and GC collections had no effect. Basically, the classic telltale signs of a managed memory leak.
Our first mistake was to try to find the leak manually, by code reviews. We’re a strong, two-man team, and we know the code pretty darn well, so we figured this was only a matter of catching the ill-written line or two. The second mistake was finding an ill-written line or two which made us feel good about solving the problem. J
After realizing that our solution did not help one bit – we told ourselves to get serious about it, and start profiling. Oh, the Ants Memory profiler kicks so much ass... After adding a “GC Collect” button to our application (a great feature to have in any memory profiler, btw) we were good to go.
We’ve distilled the least amount of work required to recreate the leak, took a memory snapshot for the “before”, performed that action 5 times, and then took another snapshot (actually, add “frantically pressing the GC Collect button” before any snapshot). The reason to do the action 5 times was to easily identify which objects count grew by a multiply of 5, since some objects are added for valid reasons, and do get cleaned between actions. I don’t know if it’s a best practice, but it works).
After finding such type (which has a multiple of 5 new instances) – reviewing the reference graph for one such instance is dead simple. I am, however, dead stupid, so I offset it a bit: they put a large red box at the bottom of the screen, next to the relevant instance, with a big red arrow stating “START HERE”, but I keep ignoring it, and go straight to the GC roots. Something inside me keeps telling me that it’s more important. I can’t fight it. Only after I’m persuaded to start following the graph from the right place – I can start seeing the problems.
The problem was, btw, the old familiar case of databinding to a non-INotifyPropertyChanged object, which, well… leaks. We just missed that databinding in our code review.
Other good memory leaks:
http://blogs.msdn.com/jgoldb/archive/2008/02/04/finding-memory-leaks-in-wpf-based-applications.aspx
Hey folks.
I have an extensible system, where an addin can add a new UI component in the form of a ViewModel object, and a corresponding DataTemplate.
My app needs a way to load all of those DataTemplates as resources before the ViewModel is “shown” – so a dynamic resource location is required.
At some “UI initialization” point I have this piece of code:
var resourceUris = _Services.OptionPacksProvider.AllPacks.SelectMany(
x => x.ResourceUriForDataTemplates).Distinct();
foreach (Uri resourceUri in resourceUris)
{
_View.Resources.MergedDictionaries.Add(new ResourceDictionary { Source = resourceUri });
}
And every option pack is responsible to return the URI. It does that using a nice little method, which works based on the convention that for a viewmodel class called “Project.Namespace.XXXViewModel” – there’s a resource dictionary file adjacent to it (in the same project folder) called “XXXView.xaml”. It’s a good convention regardless.
Using the following method you get the pack URI for the resource dictionary:
public static Uri Locate<TViewModel>() where TViewModel : ViewModelBase
{
var viewmodelType = typeof(TViewModel);
string shortAssemblyName = viewmodelType.Assembly.GetName().Name;
string trimmedNamespace = viewmodelType.Namespace.Substring(shortAssemblyName.Length);
string locationBasedOnNamespace = trimmedNamespace.Replace(".", @"/");
var viewModelName = viewmodelType.Name.TrimX("Model");
return new Uri(string.Format(@"pack://application:,,,/{0};component{1}/{2}.xaml",
shortAssemblyName, locationBasedOnNamespace, viewModelName));
}
(Caveats: the project name should equal the assembly name, and the default namespace should equal the project name)
Me like!
int sleepTime = 1.Seconds();
while (condition)
{
Thread.Sleep(sleepTime*=2);
if(sleepTime>10.Minutes())
{
//give up
return;
}
}
DoWork();
And no, those extensions are not defined under the System namespace.
I read a nice post by Ron Gross (thanks for sharing, Ken) about how a file locked by the System process screws up a build.
I have only one thing to say to that:
What?! Only one file?!?
I’m a big FinalBuilder fan, and my build/deployment scripts usually have countermeasures for that sort of build-wrecking scenarios.
Above is a short snippet out of a deployment script I wrote (those actions are part of the uninstallation of a previous version). After performing the mundane action of “stop the service” – we continue to the extremes: kill the process in case it decided to mutiny, kill all open file handles, kill all MMC session (which could screw up a service uninstallation) and so on, and so forth.
All these tasks are based on the wonderful PsTools by SysInternals, and provided out of the box as FinalBuilder actions.
http://blogs.jetbrains.com/dotnet/2009/10/resharper-50-overview/
Except for the ASP features (which I literally didn’t even skim through) - just about very new feature made me giggle with joy.
I think I can no longer live without the new 5.0 features, and I haven’t even tried them.
(I just love Resharper’s CamelHumps.)
PCEH, if you’re lacking in the Resharper department (and/or don’t use WPF) is PropertyChangedEventHandler, and the simple invoker allows you to write cool code like this:
PropertyChanged.InvokeIfNeededX(sender, () => MyDataBoundProperty);
A simple extension method for PropertyChangedEventHandler class, and you get a wonderful syntax for safe invocations. Code below:
using System.Linq.Expressions;
namespace System.ComponentModel
{
public static class PropertyChangedEventHandlerExtensions
{
public static void InvokeIfNeededX<T>(this PropertyChangedEventHandler source, object sender, Expression<Func<T>> prop)
{
if (source != null)
{
source(sender, new PropertyChangedEventArgs(GetName(prop)));
}
}
private static string GetName<T>(Expression<Func<T>> expression)
{
var member = expression.Body as MemberExpression;
if (member == null)
{
throw new ApplicationException("Cannot handle expression of type " + expression.GetType());
}
return member.Member.Name;
}
}
}
More Posts
Next page »