---
title: "Bugs and Missing Features with Team System Unit Testing: Part I"
url: "https://osherove.com/blog/2006/1/25/bugs-and-missing-features-with-team-system-unit-testing-part.md"
canonical: "https://osherove.com/blog/2006/1/25/bugs-and-missing-features-with-team-system-unit-testing-part.html"
published: "2006-01-25T12:22:00"
updated: "2006-01-25T12:22:00"
tags: ["Agile Israel News", "Agile Related", "Team Agile News"]
author: "Roy Osherove"
description: "Here are a couple more examples on the immaturity of the current Team System Unit Testing in \"Quality Tools\" . Both of these were submitted to the product feedback center, which, unfortunately, only seems to have been…"
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Bugs and Missing Features with Team System Unit Testing: Part I

By Roy Osherove January 25, 2006 In [Agile Israel News](https://osherove.com/blog/category/agile-israel-news), [Agile Related](https://osherove.com/blog/category/agile-related), [Team Agile News](https://osherove.com/blog/category/team-agile-news)

**Historical article** · Originally published January 25, 2006; technical details may be outdated.

Here are a couple more examples on the immaturity of the current Team System Unit Testing in "Quality Tools" . Both of these were submitted to the product feedback center, which, unfortunately, only seems to have been catered Towards the pre-release versions of VS.NET. But I still added them anyway, just so that maybe someone looks over at them. Feel free to click on the title links and vote for them if you think they are important enough.

Both of these,BTW, apply to the situation in which you'd like to test than an Exception is indeed thrown from your code when expected.

---

This one is a bug:

[ExcepctedException Attribute's "Message" property is never checked](http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=8b2e9fff-da65-4755-91f3-33e4b3fb4ac0)

While writing a unit test with an "ExpectedException" attribute and also setting the "Message" property on the excpected exception, the test passes even though the exception that was thrown has a different message.

<table><tbody><tr id="BugView_trReproSteps"><td><strong><span id="BugView_lblReproStepsTitle">Steps to Reproduce:</span></strong></td><td><div><span id="BugView_lblReproSteps"></span>&nbsp;</div><div><span>[TestMethod]<br>[ExpectedException(typeof(InvalidOperationException),"Some Message")]<br>public void MyTest()<br>{<br>//this test will pass, but it should fail on the exception&nbsp; message being wrong<br>throw new InvalidOperationException("Some Other Message");<br>}</span></div></td></tr></tbody></table>

How this one went by into the release is a mystery to me. Obviously no onw has ever used this functionality to actually talk about the fact that it's broken (and no one actually tested for it). Bad.

---

Here's the second one - it's a suggestion on a missing feature which should have been there.

[ExcpectedException should allow testing for Any Exception Type, not just derived from Exception](http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=814b4be8-8a1f-4f17-a38a-2612c1adc1e2)

Example:

\[TestMethod\]
\[ExpectedException(typeof(Exception),"Some Message")\]
public void MyTest()
{
//this test will NOT COMPILE claiming that the attribute requires something that DERIVES from Exception

...

}

\[TestMethod\]
\[ExpectedException(typeof(InvalidOperationException),"Some Message")\]
public void MyTest()
{
//this test WILL COMPILE

...

} 

Right now if I want to write a test than expects an exception, I have to make sure that the thrown exception \*has\* to derive from Exception, and cannot use the Generic Exception object.
In many cases, developers would like to use a generic exception, either because they are not sure what exception the code will throw, or they just want to use the simplest thing that works.
The current situation makes the developer find some other generic exception, against their better judgment.

This is different than the default behavior in NUnit and I'm curious as to why this is so.

---

Here are some more observations:

The Test List Window is not Usable for Test Driven Development:

- **When the tests are running, you get to see a list of \*all the tests\*.** Passing and failing together. If I'm working with Test Driven Development, the last test is usually the one to fail, but that last test is also usually located waaay down then on the bottom of the list, making me scroll to reach it every time. It's be OK if I could at least **sort** the list based on pass/fail status, **but I can't!**.
- **Workaround**: Use TestDriven.NET. It only shows you the failed tests.

- **If a test fails, double clicking on it opens the test failure description dialog page, instead of the failing code**. I guess that's OK if that was a regular test, but for unit tests, the default behavior should at least be configurable to jump to the code of the test. Not only that: for an exception, it should put me exactly where the exception occurred (just like double clicking on a call stack line in the output window) . 
- **Workaround**: Use TestDriven.NET: it allows clicking on a line of an exception or error in call stack, and it puts you right on that line in the code editor.

- **Running the tests does not necessarily invoke the \*build\* process**. so in Test Driven Development, I have to continuously Build (Ctrl-Shift-B), and then run the current test project (Ctrl-Shift-X). Unacceptable, and should at least be configurable.
- **Workaround**: Use TestDriven.NET : running tests automatically invokes the build first

- **No default hierarchical view of the tests by namespace/class**. If you're trying to build an NUnit killer, at least build in the correct UI like NUnit inside the IDE. Right now, if I want to run only some of the test, I have to manually arrange them by class, or namespace, and create my own test lists. That sucks, I'd like a default arrangement that I can use ad-hoc.
- **Workaround**: Use the latest version of NUnit GUI. It  allows running Team System Unit Tests these days too. Just point it at your Team System Dll with unit tests and your'e good to go.

## More in Agile Israel News

[All posts in Agile Israel News](https://osherove.com/blog/category/agile-israel-news)

- Feb 1, 2006

    ### [\[Audio Interview\] Johanna Rothman - Secrets of great management](https://osherove.com/blog/2006/2/1/audio-interview-johanna-rothman-secrets-of-great-management.html)

- Feb 1, 2006

    ### [\[Audio Interview\] Kent Beck - An Agile conversation (First Iteration)](https://osherove.com/blog/2006/2/1/audio-interview-kent-beck-an-agile-conversation-first-iterat.html)

- Jan 23, 2006

    ### [TestDriven.NET aims to become a commercial product with added features](https://osherove.com/blog/2006/1/23/testdrivennet-aims-to-become-a-commercial-product-with-added.html)

- Jan 23, 2006

    ### [MS Israel Security Users Group is back in business](https://osherove.com/blog/2006/1/23/ms-israel-security-users-group-is-back-in-business.html)


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/
