Develop Reference

Compare contents of System.Text.JsonDocument C# in unit test

I feel like I'm taking crazy pills here... but how can I compare two JsonDocuments (or JsonElements or what have you) for JSON equality, i.e. same keys with same values?
To limit the scope, the ability to perform this comparison in a unit test is sufficient unto the day.
I have a unit test in which I want to compare the result of a function that returns a JsonDocument to some expected value. Things that don't work include using FluentAssertions.Json (because my type is not JObject), and comparing the value of GetRawText because I don't care about the whitespace.
I guess I could write the strings out and re-serialize them or something but this honestly feels like such a hack that I must be doing something wrong.
I understand the business logic of comparing them, I have seen the other questions like this and this. The first is much more in keeping with what I want, it's just an embarrassing result for C#...
The second is not what I need at all.

Thanks to #ChristophLütjen for identifying the fix I needed in this issue
Given two JsonDocuments I can compare them using FluentAssertions like this:
Doc1.RootElement.Should().BeEquivalentTo(Doc2.RootElement, opt => opt.ComparingByMembers<JsonElement>());
I'm still bemused that there is not a more straightforward comparison method out there for the general case, but since my immediate use was unit testing, I'm satisfied with this result.

How to assert multiple variables simultaneously with NUnit?

This ought to be possible - and I think it might be possible somehow using Constraints, but they seem to only take one variable as input, which fails.
Here's the simplest example I've run into:
I have an object with size (i.e. a 2D variable)
I need to show it's partly off-screen
This happens if x is outside a range OR y is outside a range
... I can't see how to achieve that in NUnit (without throwing away critical info)
It seems that NUnit fundamentally doesn't support anything other than 1-dimensional problems, which would be absurd, so I must be missing something here. But the only methods I can find all only work with 1-d inputs.
Things I've thought of ... but don't work:
i. Assert.True( A | B ) - useless: it throws away all the "expected" info and generates such weak messages that there's essentially no point using a testing framework here
ii. Assert.Or - doesn't allow multiple variables, so you can test "X is 3, or 4, or 5", but you cannot test "X is 3, or Y is 4"
iii. Writing custom assertions for a Tuple<A,B> - but then it goes horribly wrong when you get to "greater than" ... is "<A,B> greater than <C,D>" is a non-trivial question and ends up with code that's vastly confusing and I can guarantee someone will misunerstand and misapply it in future (probably me :))

1-dimensional problems
To be frank I don't really get it. If you think of it, actually all members in Assert are tools for boolean problems (zero dimension). Which perfectly makes sense for raising a red or green flag in case of all assertions.
Your problem is also a yes/no question: "Is my object off-screen?".
i. Assert.True( A | B ) - useless: it throws away all the "expected" info and generates such weak messages
Nothing stops you to specify the message, which is displayed if the assertion fails:
Assert.IsTrue(myObject.IsOnScreen(), $"Object is off-screen: {myObject.Bounds}")
But in this particular case you can easily turn it into an equality assertion:
// here also the default message may be clear enough
Assert.AreEqual(expected: screenBounds, actual: screenBounds.UnionWith(myObject.Bounds));
And voila, multiple (four) properties were compared at once...

To be honest, you haven't done a great job of explaining what you want. I re-read several times and I think I have guessed right, but I shouldn't have to so please try code for the next problem.
I take it that you wish it were possible to change the actual value in the course of an NUnit constraint expression... something like this...
// NOT WORKING CODE
Assert.That(X, Is.OnScreen.And.That(Y, Is.OnScreen));
(Where "OnScreen" makes the test you need)
But you can't do that. To work within the existing features of NUnit, each Assertion needs to deal with one actual value.
Simplest thing I can think of is to use multiple assertions:
Assert.Multiple(() =>
{
Assert.That(X.IsOnScreen);
Assert.That(Y.IsOnScreen);
});
I say this is simple because NUnit already does it. It's not very expressive, however.
If you are doing a lot of such tests, the simplest thing is to create a custom constraint, which deals with your objects as an entity. Then you would be able to write something like
Assert.That(myObject, Is.OnScreen);
Not just as pseudo-code, but as actual code. Basically, you would be creating a set of tests on rectangles, representing the object bounds on the one hand and the screen dimensions on the other.

Is there a simpler way to call Contains() on a string that is potentially null?

Is there a simpler or less ugly way to call .Contains() on a string that is potentially null then by doing:
Assert.IsTrue((firstRow.Text ?? "").Contains("SomeText"));

I'd suggest using Assert.That syntax:
Assert.That(firstRow.Text, Does.Contain("SomeText"));
If you need to check that text is not containing a certain string:
Assert.That(firstRow.Text, Does.Not.Contain("SomeText"));

I think any of these alternatives are better, even though they are not quite as short:
// 1
Assert.IsTrue(firstRow.Text != null && firstRow.Text.Contains("SomeText"));
// 2
Assert.IsNotNull(firstRow.Text);
Assert.IsTrue(firstRow.Text.Contains("SomeText"));
// 3
var text = firstRow.Text;
Assert.IsTrue(text != null && text.Contains("SomeText"));
I think "simple" is a subjective term. Simple, to me, means "clear and easy to read", not "fewest number of characters".
Considering that this code appears to be part of a unit test, Option #2 would be best, because then you can tell from reading the test results whether the test failed due to a null value or failed because the value did not contain the expected text. Otherwise, you would have to re-execute this test with a debugger and look at the value at runtime in order to distinguish between these two cases.
"Make things as simple as possible, but not simpler." - Albert Einstein

This is one character shorter, but frankly I like your original code better.
Assert.IsTrue((firstRow.Text + "").Contains("SomeText"));

No, there aren't any. But you could write an extension method for that:
public static bool SContains(this string source, string query)
{
return source != null && source.Contains(query);
}

I would expect the string being null exposes a different error to the string not being "SomeText", in which case it would be better to have two unit tests to test the different outcomes.
In terms of methods how about using StringAssert and IsNotNull?
Assert.IsNotNull(firstRow.Text);
StringAssert.Contains(firstRow.Text, "SomeText");
(I am assuming this relates to a unit test)

According to http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.stringassert(v=vs.100).aspx
StringAssert class can be used to easily assert whether or not the stringUnderTest contains the specefied string

I think a plain No,
This would be a little less ugly and gets the implied readability
If(!string.IsNullOrEmpty(firstRow.Text))
Assert.IsTrue(firstRow.Text.Contains("SomeText"));

I would generally use something more like the following which is longer and less clever but idiomatic c# and the intent is obvious.
Assert.IsTrue( !string.IsNullOrWhiteSpace(firstRow.Text))
Assert.IsTrue( firstRow.Text.Contains("SomeText"));
In my interpretation of the question, the empty string is an error condition. That's one reason I prefer my version - the context for the test is explicit. If I wanted to include the empty string as a valid result I would use the following as the first condition, again making the test explicit:
Assert.IsNotNull(firstRow.Text)
To me this is far more important than shortening the code. In a month when I (or someone else) come back to make changes to the code it is obvious what the intent of the test is. In the original question, not so much.

multiple expectations/assertions to verify test result

I have read in several book and articles about TDD and BDD that one should avoid multiple assertions or expectations in a single unit test or specification. And I can understand the reasons for doing so. Still I am not sure what would be a good way to verify a complex result.
Assuming a method under test returns a complex object as a result (e.g. deserialization or database read) how do I verify the result correctly?
1.Asserting on each property:
Assert.AreEqual(result.Property1, 1);
Assert.AreEqual(result.Property2, "2");
Assert.AreEqual(result.Property3, null);
Assert.AreEqual(result.Property4, 4.0);
2.Relying on a correctly implemented .Equals():
Assert.AreEqual(result, expectedResult);
The disadvantage of 1. is that if the first assert fails all the following asserts are not run, which might have contained valuable information to find the problem. Maintainability might also be a problem as Properties come and go.
The disatvantage of 2. is that I seem to be testing more than one thing with this test. I might get false positives or negatives if .Equals() is not implemented correctly. Also with 2. I do not see, what properties are actually different if the test fails but I assume that can often be addressed with a decent .ToString() override. In any case I think I should avoid to be forced to throw the debugger at the failing tests to see the difference. I should see it right away.
The next problem with 2. is that it compares the whole object even though for some tests only some properties might be significant.
What would be a decent way or best practise for this in TDD and BDD.

Don't take TDD advice literally. What the "good guys" mean is that you should test one thing per test (to avoid a test failing for multiple reasons and subsequently having to debug the test to find the cause).
Now test "one thing" means "one behavior" ; NOT one assert per test IMHO.
It's a guideline not a rule.
So options:
For comparing whole data value objects
If the object already exposes a usable production Equals, use it.
Else do not add a Equals just for testing (See also Equality Pollution). Use a helper/extension method (or you could find one in an assertion library) obj1.HasSamePropertiesAs(obj2)
For comparing unstructured parts of objects (set of arbitrary properties - which should be rare),
create a well named private method AssertCustomerDetailsInOrderEquals(params) so that the test is clear in what part you're actually testing. Move the set of assertions into the private method.

With the context present in the question I'd go for option 1.
It likely depends on context. If I'm using some sort of built in object serialization within the .NET framework, I can be reasonably assured that if no errors were encountered then the entire object was appropriately marshaled. In that case, asserting a single field in the object is probably fine. I trust MS libraries to do the right thing.
If you are using SQL and manually mapping results to domain objects I feel that option 1 makes it quicker to diagnose when something breaks than option 2. Option 2 likely relies on toString methods in order to render the assertion failure:
Expected <1 2 null 4.0> but was <1 2 null null>
Now I am stuck trying to figure out what field 4.0/null was. Of course I could put the field name into the method:
Expected <Property1: 1, Property2: 2, Property3: null, Property4: 4.0>
but was <Property1: 1, Property2: 2, Property3: null, Property4: null>
This is fine for small numbers of properties, but begins to break down larger numbers of properties due to wrapping, etc. Also, the toString maintenance could become an issue as it needs to change at the same rate as the equals method.
Of course there is no correct answer, at the end of the day, it really boils down to your team's (or your own) personal preference.
Hope that helps!
Brandon

I would use the second approach by default. You're right, this fails if Equals() is not implemented correctly, but if you've implemented a custom Equals(), you should have unit-tested it too.
The second approach is in fact more abstract and consise and allows you to modify the code easier later, allowing in the same way to reduce code duplication. Let's say you choose the first approach:
You'll have to compare all properties in several places,
If you add a new property to a class, you'll have to add a new assertion in unit tests; modifying your Equals() would be much easier. Of course you have still to add a value of the property in expected result (if it's not the default value), but it would be shorter to do than adding a new assertion.
Also, it is much easier to see what properties are actually different with the second approach. You just run your tests in debug mode, and compare the properties on break.
By the way, you should never use ToString() for this. I suppose you wanted to say [DebuggerDisplay] attribute?
The next problem with 2. is that it compares the whole object even though for some tests only some properties might be significant.
If you have to compare only some properties, than:
ether you refactor your code by implementing a base class which contains only those properties. Example: if you want to compare a Cat to another Cat but only considering the properties common to Dog and other animals, implement Cat : Animal and compare the base class.
or you do what you've done in your first approach. Example: if you do care only about the quantity of milk the expected and the actual cats have drunk and their respective names, you'll have two assertions in your unit test.

Try "one aspect of behavior per test" rather than "one assertion per test". If you need more than one assertion to illustrate the behavior you're interested in, do that.
For instance, your example might be ShouldHaveSensibleDefaults. Splitting that up into ShouldHaveADefaultNameAsEmptyString, ShouldHaveNullAddress, ShouldHaveAQuantityOfZero etc. won't read as clearly. Nor will it help to hide the sensible defaults in another object then do a comparison.
However, I would separate examples where the values had defaults with any properties derived from some logic somewhere, for instance, ShouldCalculateTheTotalQuantity. Moving small examples like this into their own method makes it more readable.
You might also find that different properties on your object are changed by different contexts. Calling out each of these contexts and looking at those properties separately helps me to see how the context relates to the outcome.
Dave Astels, who came up with the "one assertion per test", now uses the phrase "one aspect of behavior" too, though he still finds it useful to separate that behavior. I tend to err on the side of readability and maintainability, so if it makes pragmatic sense to have more than one assertion, I'll do that.

Why does the "Assert" class have so many seemingly redundant methods? When should each be used?

So I see that Assert has dozens of methods that seem to do essentially the same thing.
Assert.IsFalse( a == b );
Assert.IsTrue( a != b );
Assert.AreNotEqual( a, b );
Why? Is it just to be more explicit? When should the various methods be used? Is there an offical best practices document?

The difference between IsFalse and IsTrue is readability. AreNotEqual allows a better error message to be presented when the test fails. IsTrue for example will just tell you that the answer was supposed to be true and was really false. AreNotEqual will show the two values that were compared in its error message.

Short answer: For readability.
Slightly longer answer:
Your tests are also code, and in terms of intent are as important as the code you are testing. As such, you want to make the intent of the test as clear as possible. Sometimes that means you use IsFalse, sometimes it means using IsTrue.

Those three methods have three different, specific goals. The goal of testing is to provide clear verification and validation of your code. By using the most clear and specific method possible, you're making your test the smallest test possible, with the most specific, clear meaning possible.
This helps because it adds clarity - you can see, specifically, what a test is supposed to do in a more declarative nature, where using the same method for multiple testing scenarios, which each have a different meaning, requires more understanding of the code itself, instead of the nature of the test.
In this case, the third is the (only) appropriate one to use. However, if you had this situation, you'd use a different one, for example:
Assert.IsTrue( myClass.MethodThatReturnsTrue() );
You should use the method that provides the most clarity as to your goal - if you're checking two values for equality, use Assert.IsEqual, if you're checking a boolean to verify that it's false, use Assert.IsFalse. This makes the error reports meaningful and understandable.

It makes the errors easiest to read; use the one that matches your code most closely.
In this case, use #3.

Because you can overload the == and != , thats why.

It's called a "Fluent Interface"... and makes things more readable in the opinion of many.