How (not) to use mstest
-
There are several rants on the functionality of mstest... Yes, it offers a little less than other unit test frameworks. But there are geniuses using it. What about:
Assert.AreEqual(actual, expected, "Value is wrong: {0}, expected: {1}.", actual, expected);
That guy always wrote a custom message showing both the actual and the expected value. Has he ever read the message of a failing test? Let's try with
int expected = 42; int actual = 7;. The message is:Assert.AreEqual failed. Expected:<7>. Actual:<42>. Value is wrong: 7, expected: 42.
See: another bug. Strangely, intellisense shows the signature correctly:
Assert.AreEqual(int expected, int actual, string message, params object[] parameters) (+17 overloads)
Well, even mstest is better than some professionals. :( [Edit] Strange that I need to explain further... The mstest framework works here absolutely the way it is documented, without any bugs. A potential source of confusion is the order of arguments to Assert.AreEqual - NUnit does it the other way round. But intellisense shows it correctly, so anyone looking at the screen when writing the test will see where "actual" and "expected" have to go. For testing your tests, you are expected to show that your test can fail, aren't you? At that moment, you will see the failure message. And now you have another opportunity to see where actual and expected should go: even when you do not provide a custom message mstest will tell you "Assert.AreEqual failed. Expected:<7>. Actual:<42>.", if you provide a custom message that will be appended. And thus you'll see that you do not need to repeat actual and expected in your custom message. What happened to CodeProject that I need to say that so explicitly? :~ [/Edit]
-
There are several rants on the functionality of mstest... Yes, it offers a little less than other unit test frameworks. But there are geniuses using it. What about:
Assert.AreEqual(actual, expected, "Value is wrong: {0}, expected: {1}.", actual, expected);
That guy always wrote a custom message showing both the actual and the expected value. Has he ever read the message of a failing test? Let's try with
int expected = 42; int actual = 7;. The message is:Assert.AreEqual failed. Expected:<7>. Actual:<42>. Value is wrong: 7, expected: 42.
See: another bug. Strangely, intellisense shows the signature correctly:
Assert.AreEqual(int expected, int actual, string message, params object[] parameters) (+17 overloads)
Well, even mstest is better than some professionals. :( [Edit] Strange that I need to explain further... The mstest framework works here absolutely the way it is documented, without any bugs. A potential source of confusion is the order of arguments to Assert.AreEqual - NUnit does it the other way round. But intellisense shows it correctly, so anyone looking at the screen when writing the test will see where "actual" and "expected" have to go. For testing your tests, you are expected to show that your test can fail, aren't you? At that moment, you will see the failure message. And now you have another opportunity to see where actual and expected should go: even when you do not provide a custom message mstest will tell you "Assert.AreEqual failed. Expected:<7>. Actual:<42>.", if you provide a custom message that will be appended. And thus you'll see that you do not need to repeat actual and expected in your custom message. What happened to CodeProject that I need to say that so explicitly? :~ [/Edit]
It's what I like to call the Microsoft 85% Principle. Pretty much all of their products are worked upon until they're approximately 85% complete and working. After that, functionality it either left missing or broken. :laugh:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
-
There are several rants on the functionality of mstest... Yes, it offers a little less than other unit test frameworks. But there are geniuses using it. What about:
Assert.AreEqual(actual, expected, "Value is wrong: {0}, expected: {1}.", actual, expected);
That guy always wrote a custom message showing both the actual and the expected value. Has he ever read the message of a failing test? Let's try with
int expected = 42; int actual = 7;. The message is:Assert.AreEqual failed. Expected:<7>. Actual:<42>. Value is wrong: 7, expected: 42.
See: another bug. Strangely, intellisense shows the signature correctly:
Assert.AreEqual(int expected, int actual, string message, params object[] parameters) (+17 overloads)
Well, even mstest is better than some professionals. :( [Edit] Strange that I need to explain further... The mstest framework works here absolutely the way it is documented, without any bugs. A potential source of confusion is the order of arguments to Assert.AreEqual - NUnit does it the other way round. But intellisense shows it correctly, so anyone looking at the screen when writing the test will see where "actual" and "expected" have to go. For testing your tests, you are expected to show that your test can fail, aren't you? At that moment, you will see the failure message. And now you have another opportunity to see where actual and expected should go: even when you do not provide a custom message mstest will tell you "Assert.AreEqual failed. Expected:<7>. Actual:<42>.", if you provide a custom message that will be appended. And thus you'll see that you do not need to repeat actual and expected in your custom message. What happened to CodeProject that I need to say that so explicitly? :~ [/Edit]
What about people testing the framework?
Assert.AreEqual(int.Parse("42"), 42);
If that piece of code starts to fail you've got bigger problems than a failing unit test :omg: Just stick to testing your own code (and maybe some external code you expect to change) :doh:
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
There are several rants on the functionality of mstest... Yes, it offers a little less than other unit test frameworks. But there are geniuses using it. What about:
Assert.AreEqual(actual, expected, "Value is wrong: {0}, expected: {1}.", actual, expected);
That guy always wrote a custom message showing both the actual and the expected value. Has he ever read the message of a failing test? Let's try with
int expected = 42; int actual = 7;. The message is:Assert.AreEqual failed. Expected:<7>. Actual:<42>. Value is wrong: 7, expected: 42.
See: another bug. Strangely, intellisense shows the signature correctly:
Assert.AreEqual(int expected, int actual, string message, params object[] parameters) (+17 overloads)
Well, even mstest is better than some professionals. :( [Edit] Strange that I need to explain further... The mstest framework works here absolutely the way it is documented, without any bugs. A potential source of confusion is the order of arguments to Assert.AreEqual - NUnit does it the other way round. But intellisense shows it correctly, so anyone looking at the screen when writing the test will see where "actual" and "expected" have to go. For testing your tests, you are expected to show that your test can fail, aren't you? At that moment, you will see the failure message. And now you have another opportunity to see where actual and expected should go: even when you do not provide a custom message mstest will tell you "Assert.AreEqual failed. Expected:<7>. Actual:<42>.", if you provide a custom message that will be appended. And thus you'll see that you do not need to repeat actual and expected in your custom message. What happened to CodeProject that I need to say that so explicitly? :~ [/Edit]
Worse is (and I'm not sure about NUnit) here, that .AreEqual uses obj.Equals for comparison by default. It has overloads for common value types, but in some cases can yield surprises. Generally, I think many test frameworks suffer from featuritis. It is better to simply have an Assert() method, taking a single Boolean expression, than have the possibility of bugs or unexpected behaviour in the test framework.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
