← Back to team overview

nunit-core team mailing list archive

[Bug 550398] [NEW] Feature: Implement Is.ListEquivalentTo

 

Public bug reported:

== CONTEXT ==

I am implementing a class which serializes a custom binary format. My
tests are of the form:

[Test]
public void Test_FrobSerializer()
{
   MemoryStream buffer = new MemoryStream();
   MyBinaryWriter writer = new MyBinaryWriter(buffer);
   writer.WriteFrob(new Frobber(0x00, 0x11, 0x22, 0x33));
   Assert.That(buffer.ToArray(), Is.EquivalentTo(new byte[] {0x00, 0x11, 0x22, 0x33});
}

== ISSUE ==

I had a bug sneak through, because the Is.EquivalentTo assertion is too
weak in this case: I happened to get the order of two parameters
internally mixed up, and writer.WriteFrob was writing { 0x00, 0x22,
0x11, 0x33 }.

The two arrays were 'collection' equivalent, in that they held the same
values in the same quantity, but what I needed was 'list' equivalence,
because the proper ordering of the values is important here.

== REQUEST ==

My request is for the following to be realizable:

[Test]
public void MetaTest()
{
   // Ideally, Is.EquivalentTo gets renamed to differentiate the two forms of collection equivalence.
   // However, I recognize this to be a breaking change, and I suspect that the benefit of a name
   // change is insufficient to justify breaking compatability.
   Assert.That(new byte[] {0x00, 0xFF}, Is.CollectionEquivalentTo(new byte[] {0x00, 0xFF}));
   Assert.That(new byte[] {0x00, 0xFF}, Is.CollectionEquivalentTo(new byte[] {0xFF, 0x00}));

   Assert.That(new byte[] {0x00, 0xFF}, Is.ListEquivalentTo(new byte[] {0x00, 0xFF}));
   Assert.That(new byte[] {0x00, 0xFF}, Is.Not.ListEquivalentTo(new byte[] {0xFF, 0x00}));
}

== IMPLEMENTATION ==

As a cheap hack, call Enumerable.ToArray() on both enumerables, then go
through them in a for loop and call Equals() a bunch. Forces you to do a
shallow array copy. Should be fine for a first pass.

A nicer form would manipulate the enumerators by hand (as they can't be
put in a foreach statement).

** Affects: nunitv2
     Importance: Undecided
         Status: New

-- 
Feature: Implement Is.ListEquivalentTo
https://bugs.launchpad.net/bugs/550398
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.

Status in NUnit V2 Test Framework: New

Bug description:
== CONTEXT ==

I am implementing a class which serializes a custom binary format. My tests are of the form: 

[Test]
public void Test_FrobSerializer()
{
   MemoryStream buffer = new MemoryStream();
   MyBinaryWriter writer = new MyBinaryWriter(buffer);
   writer.WriteFrob(new Frobber(0x00, 0x11, 0x22, 0x33));
   Assert.That(buffer.ToArray(), Is.EquivalentTo(new byte[] {0x00, 0x11, 0x22, 0x33});
}

== ISSUE ==

I had a bug sneak through, because the Is.EquivalentTo assertion is too weak in this case: I happened to get the order of two parameters internally mixed up, and writer.WriteFrob was writing { 0x00, 0x22, 0x11, 0x33 }.

The two arrays were 'collection' equivalent, in that they held the same values in the same quantity, but what I needed was 'list' equivalence, because the proper ordering of the values is important here.

== REQUEST ==

My request is for the following to be realizable:

[Test]
public void MetaTest()
{
   // Ideally, Is.EquivalentTo gets renamed to differentiate the two forms of collection equivalence.
   // However, I recognize this to be a breaking change, and I suspect that the benefit of a name
   // change is insufficient to justify breaking compatability.
   Assert.That(new byte[] {0x00, 0xFF}, Is.CollectionEquivalentTo(new byte[] {0x00, 0xFF}));
   Assert.That(new byte[] {0x00, 0xFF}, Is.CollectionEquivalentTo(new byte[] {0xFF, 0x00}));

   Assert.That(new byte[] {0x00, 0xFF}, Is.ListEquivalentTo(new byte[] {0x00, 0xFF}));
   Assert.That(new byte[] {0x00, 0xFF}, Is.Not.ListEquivalentTo(new byte[] {0xFF, 0x00}));
}

== IMPLEMENTATION ==

As a cheap hack, call Enumerable.ToArray() on both enumerables, then go through them in a for loop and call Equals() a bunch. Forces you to do a shallow array copy. Should be fine for a first pass.

A nicer form would manipulate the enumerators by hand (as they can't be put in a foreach statement).





Follow ups

References