That approach is quite similar to what I would do myself. Given that almost all automated testing revolves around testing that some actual result is equal to some expected outcome, I never really understood why people wouldn't want to unit test equality itself.
With a value object like the above, it can easily become a bit tedious, as it leads to many tests which are all very similar.
One hack you could use with xUnit.net is this:
[Theory]
[InlineData("other first name", null, null, null, null, null, null)]
[InlineData(null, "other last name", null, null, null, null, null)]
[InlineData(null, null, "other company", null, null, null, null)]
[InlineData(null, null, null, "other street", null, null, null)]
[InlineData(null, null, null, null, "other city", null, null)]
[InlineData(null, null, null, null, null, "other zip", null)]
[InlineData(null, null, null, null, null, null, "other@email.com")]
public void EqualsIsFalseWhenAtLeastOneValueDiffers(
string firstName,
string lastName,
string company,
string street,
string city,
string zip,
string email)
{
Fixture fix = new Fixture();
var sut = fix.CreateAnonymous<CoreAddress>();
var other = new CoreAddress(
firstName ?? sut.Firstname,
lastName ?? sut.Lastname,
company ?? sut.Company,
street ?? sut.Street,
city ?? sut.City,
zip ?? sut.Zip,
email ?? sut.Email);
Assert.False(sut.Equals(other));
}
However, while it's compact, I'm not too keen on doing something like this, as the test itself has a cyclomatic complexity of 8 - which is about 7 too much... Only a slight misconfiguration of the input values could ruin the test and in the end produce either false positives or false negatives.
On the other hand, we're all programmers here, and if things become repetitive, what should we do?
Write some code to take away the tedium. This is basically what the AutoFixture.Idioms project is all about, and while it doesn't currently have an encapsulated test like the one above, it might get one in the future... it's open source, and we do occasionally take pull requests ;)