--- title: "Unit Testing in Whidbey - some pointers for improvement" url: "https://osherove.com/blog/2004/6/13/unit-testing-in-whidbey-some-pointers-for-improvement.md" canonical: "https://osherove.com/blog/2004/6/13/unit-testing-in-whidbey-some-pointers-for-improvement.html" published: "2004-06-13T18:15:00" updated: "2004-06-13T18:15:00" tags: [".Net Original"] author: "Roy Osherove" description: "Jim Newkirk - apparently the guy in charge of all the Unit Testing stuff in VS Team System, and the guy who co-wrote Nunit , shows us a new object in the Unit Testing Framework of VSTS(Team system) - PrivateObject . The…" 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/" --- # Unit Testing in Whidbey - some pointers for improvement By Roy Osherove June 13, 2004 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published June 13, 2004; technical details may be outdated. [Jim Newkirk](http://weblogs.asp.net/jamesnewkirk) \- apparently the guy in charge of all the Unit Testing stuff in VS Team System, and the guy who co-wrote [Nunit](http://www.nunit.org/), shows us a new object in the Unit Testing Framework of VSTS(Team system) - [PrivateObject](http://weblogs.asp.net/jamesnewkirk/archive/2004/06/07/150361.aspx). The whole idea behind the object is that you can Test Private methods inside your tested class. So what happens is that when you auto-generate unit tests, and you have a TestClass.PrivateMethod() - You will automatically get a class that **inherits** from PrivateObject,  which exposes all the private methods as well, as if they were public, essentially calling PrivateObject.Invoke(“MyPrivateMethodName“) underneath the covers. Think “Web Service Proxies“, only different :) What I like about this is that it's a very elegant solution to an age old problem - How do you test Private methods without “exposing“ them as public? (the question of whether you should even test private methods at all is in itself a matter of religion. Think VB vs. C#, only different :) ) Anyway - that's cool. Kudos. I like the fact that if I **wanted to** I could do it. But now, for some more pressing matters. I have a couple of points to make about Unit Testing in Whidbey: - I want to do a simple Red-Green-Refactor cycle. Why can't I do that in the simplest way possible? The simplest way for me would be to: - Create a test project (not from the wizard! I don't want to do load testing, ugh. I just want to build a class, got it?) - Create a test that does not even compile - Make it compile by adding a new Tested Project - Make the test compile and fail (this is where you get stuck) - Like I said - the last stage can't be done this simple because: - You can't run your unit tests unless you have specified a Test Configuration scheme. So: - Now I need to add **another** test project which will automatically contain a test configuration scheme (yep - that's the only way to do it. I asked Jim) - **now** you can run your tests. ugh. - Like Peter Provost wrote - it would be nice to have auto-creation of non existing classes, not just non-existing methods. - I want to be able to just add a test class to any project, not just a test project. - What's with the Assert.Inconclusive? It either fails or it passes, right? Assert.Inconclusive == Fail Otherwise I love some of the newer stuff, like the fact that you have an object test bed - You can right click on a class and instantiate that object using dialog provided parameters. (this is all in design time). Then you have this object sitting there and you can invoke its methods by right click on it's icon. You can debug into the source code too. Much like what the amazing NUnit-Addin has done for me in the past (and probably well into the future). I'd love to see Ad-hoc debugging a-la Nunit-Addin style. That would be awesome. Great job guys - but still needs some major polish until I could work with it as smoothly as I can with NUnit and NUnit-Add-in today. ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Jun 16, 2004 ### [Implementing the BackgroundWorker component - today(source included)](https://osherove.com/blog/2004/6/16/implementing-the-backgroundworker-component-todaysource-incl.html) - Jun 16, 2004 ### [Problem & Solution: Allow only one instance of any MDI child form in your MDI application](https://osherove.com/blog/2004/6/16/problem-amp-solution-allow-only-one-instance-of-any-mdi-chil.html) - Jun 12, 2004 ### [Writing a VS.Net Add-in, ugh](https://osherove.com/blog/2004/6/12/writing-a-vsnet-add-in-ugh.html) - Jun 7, 2004 ### [\[Problem and solution\] Right-to-left menus get scrambled when form is maximized](https://osherove.com/blog/2004/6/7/problem-and-solution-right-to-left-menus-get-scrambled-when.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/