Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » Productivity » Unit Testing   (RSS)

Test-Driven Properties

Zero-Friction TDD post #10: In principle, defining properties (or fields, for that matter) while TDD'ing should be no different than defining methods . Again, the important part is to stay focused on the test at hand, and not become bogged down by implementation
Posted by ploeh | 1 Comments

Use The Generate Method Stub Smart Tag To Stay In The Zone

Yet Another Zero-Friction TDD Article (YAZFTA): When writing unit tests in the TDD fashion, it's important to stay in the zone and not get side-tracked by irrelevant issues. You need to avoid what I call mental context switching. Focus on writing the
Posted by ploeh | 4 Comments

Assert Messages Are Not Optional

...and now, in this week's episode of Zero-Friction TDD : Optional Assert messages that aren't optional anyway! Actually, this piece of advice comes almost directly from the xUnit Test Patterns book, so I was in doubt whether I should post it all, but
Posted by ploeh | 3 Comments

Why Use AreEqual<T>?

This is a post in my Zero-Friction TDD series. One of my colleagues recently asked my why I prefer Assert.AreEqual<T> over one of the non-generic Assert.AreEqual overloads for primitive types. In most cases, I'm very happy with the C# compiler's
Posted by ploeh | 1 Comments

3 Is Many

This is an installment in my Zero-Friction TDD series. When I was a kid, my parents taught me that many is any number above three two*; they used the simple counting sequence one, two, many . This little story may make me seem like I was an incredibly
Posted by ploeh | 1 Comments

testmethod Code Snippet

This is an installment in my Zero-Friction TDD series. If you are a regular reader of this blog, you may have noticed a certain pattern in my unit test examples (like this one ). This is because I always follow the Four-Phase Test pattern (which is a
Posted by ploeh | 1 Comments
Attachment(s): testmethod.snippet

Ignore Irrelevant Return Values

This is an installment in my Zero-Friction TDD series. Sometimes, you don't care about the return value from a particular operation. The simplest example is if you want to check that creating a new instance of a specific type will throw an exception if
Posted by ploeh | 1 Comments

Anonymous Variables

This post is an installment in my series on Zero-Friction TDD . Often when writing a unit test, the SUT 's API will force you to create objects that you really don't care about. As an example, take a look at the signature of this constructor: public Plop(
Posted by ploeh | 4 Comments

Naming Direct Output Variables

In my series of Zero-Friction TDD tips and tricks, it's time to look at naming Direct Output variables. [ TestMethod ] public void DoStuffWillReturnMessage() { // Fixture setup string expectedResult = "ploeh" ; MyClass sut = new MyClass (); // Exercise
Posted by ploeh | 1 Comments

Zero-Friction TDD

Writing good code is difficult. Unit tests are written as code, so a corollary to the first sentence is that writing good unit tests is also difficult. TDD (particularly if you interpret the last D as Design ) carries this challenge in abundance, since
Posted by ploeh | 8 Comments

Race Troubleshooting Using The Console Output In VSTS

It must be my week of discovering the obvious . The other day I was troubleshooting a race condition in my code. I had a unit test that faithfully reproduced the error, but just looking at the code involved didn't produce any sudden insights into its
Posted by ploeh | 3 Comments

cleantestresults XML Snippet

About a year ago, I wrote about an automated way to clean up the TestResults folder created by VSTS. While I still use this approach methodically, I've begun to find it tedious to find my original post to copy and paste the XML into the project file.
Posted by ploeh | 0 Comments
Attachment(s): cleantestresults.snippet

Testing Against The Passage of Time

This is the fourth in a small series of posts about testing against non-determinism. In this installation, I'm going to cover the passage of time. In my former post , I demonstrated how you can use the Provider Injection pattern to decouple your test

Test-Driven Development With Test Lists

For most of the time, I write code using the test-driven development methodology. This means that I write a bit of code, run a suite of tests, write a bit more code, run some more tests, etc. For this reason, I need unit testing to be an integrated part
Posted by ploeh | 3 Comments
 
Page view tracker