Group items tagged

"Visual Studio 2012 has a great new Test Explorer.  The Test Explorer is where you see the results of your unit tests.  In Update 1 it has been extended, and you can now organize and filter the test runs based on several conditions, among them your Projects, and Traits."

"Testing for exceptions in unit tests can be tricky. [..] The guys that designed xUnit understood the shortcomings of testing exceptions and took a much cleaner approach."

"I want to look at some of the costs of unit testing and ask the question "why is unit testing hard?" After all, if unit testing weren't hard, we wouldn't have to question whether or not it was worth it.  It makes sense then to look at first why it is hard and what makes it hard."

"One of the biggest struggles that developers have with adopting Unit Testing, whether it's Test Driven Development (TDD), Behavior Driven Development (BDD) or even just Test Eventual Development (TED), is the difficulty some code is to test.  This is typically when code doesn't follow the SOLID design principals."

"Unit tests don't find bugs. They find regressions. This is a painful lesson I learned when I first started doing TDD (test-driven development), and it's well known among most TDD circles."

"This blog poses a rather radical premise. It suggests that Refactorings have counterparts called Transformations. Refactorings are simple operations that change the structure of code without changing it's behavior. Transformations are simple operations that change the behavior of code. Transformations can be used as the sole means for passing the currently failing test in the red/green/refactor cycle. Transformations have a priority, or a preferred ordering, which if maintained, by the ordering of the tests, will prevent impasses, or long outages in the red/green/refactor cycle."

I recently discovered a very cool project on NuGet - FluentAssertions. This is a really funky little library that vastly improves assertions in your unit tests, whether you are using NUnit or MsTest.

So I tried to give some examples of when NUnit (what I use) is much nicer and more readable then this project. However Diigo comments deletes some special symbols like [ for some reason. But the point was that this article only compares to MsTest, not NUnit which can be quite readable.

"The book Growing Object Oriented Software, Guided by Tests states that you should never mock interfaces that you don't own. When I read that it caught me off guard. After all faking third party libraries that talk to databases or the network is the primary use case of a mock object right?"

"Let's look at this implementation through the lens of the Rule of Modularity. The above code fails the "simple parts, clean interfaces" sniff test."

"Recommendation: Go for the lightweight Factory Delegate approach. As with all patterns, use with caution and watch for overuse & abuse. In particular, if you need to manage state between multiple delegate, fall back to the overriding approach, because you can keep the state in the subclass."

The Joel Test: 12 Steps to Better Code Have you ever heard of SEMA? It's a fairly esoteric system for measuring how good a software team is. No, wait! Don't follow that link! It will take you about six years just to understand that stuff.

TechEd Europe 2012: typically, we write down requirements somewhere and then use it as the starting point for development. In the talk we see how these two worlds can come closer together: a requirement can be a failing test that development has to fix.

"In my post on Why SOLID Matters, we refactored a small piece of code to be more SOLID.  Granted, it was a simplistic example, but good for illustrating several key points on SOLID.  We will continue using the same code to discuss the benefits of Mocking."

"[..] the reason I have done all this work is my very strong belief that TDD as a practice has a large amount of value well beyond what most people understand. In fact, I believe that of all the practices made popular by the agile movement, TDD is the most beneficial practice overall. Here are eight reasons why I believe that TDD should be beyond debate."