First review of Typemock Racer
Note: Cross posted from The Typemock Insider Blog. Permalink And here it is. Go check it out now. Thanks Dr. Random (Casey Kramer)!
Category Archives: Uncategorized
Working with Racer
Note: Cross posted from The Typemock Insider Blog. Permalink I’m the first one who gets to break new stuff, and so, here are my impressions from Racer: It’s the greatest invention ever! What’s that? You say I’m a bit biased because I work at Typemock? You might have a point. So how’s my experience so
James Carr on TDD Anti Patterns
A long catalog of anti patterns. While interesting and lots of “I’ve done this!” moments, remember: When doing unit tests, you will make mistakes. Ok, when you program, you’ll make mistakes. You can’t say now: I got to watch out for these, you won’t write unit tests at all. Don’t let lists of patterns or
Exploratory Testing by James Bach
A quick link from James Bach on exploratory testing. The edited video is funny, and it also makes you think. QA testing is different than developer testing. QA should figure out how to break the system. Developer tests need to prove the system does what it should do. Together – you got a mighty fine
CRAP and Other Metrics
Uncle Bob on metrics for clean code. Despite what he says, and I have so much respect for the guy, don’t rush out and do it now. If you start running it on your codebase, expect a harsh reality shock. Even if you expect it, it’s still a shock. I recall doing something similar years
When to TDD an Interface
Note: Cross posted from The Typemock Insider Blog. Permalink Brett Schuchert, on the Object Mentor blog, writes about TDDing an interface. One of the main questions raised is when to decide you need an interface rather than a concrete class. The more I think about it, it comes back to your knowledge of the system.
When Should I Write A Test?
Note: Cross posted from The Typemock Insider Blog. Permalink Sam Newman asks three questions that can help you decide whether to write tests for a feature. How easy is the feature to test? What is the likelihood of the feature breaking? What is the impact of the break? Let’s start with the 2nd one. That’s
100% Code Coverage – Achievement Unlocked
Patrick Smacchia, of NDepend fame, brings arguments for pushing for maximum code coverage. We all know that it’s a problem reaching over the top to cover all the code. Patrick says 100% coverage will motivate you to keep it that way. There is some truth in that. The broken window theory states that as well.
Unit Testing is Not a “Figure It Out Later” By
Run, don’t walk, and read and the entire post (and a very emotional one at that) about why unit testing mattes. To quote the bottom line: If you care about code quality, business process, the business you work for, and respect for yourself as a quality developer, less bugs for you and your end users,
The Dark Side of Faking DateTime.Now
Note: Cross posted from The Typemock Insider Blog. Permalink Add a feature and see the support calls comes in. Our new feature of faking DateTime.Now is causing some issues. You can see Dennis’ post and Soon Hui’s post which are basically point to the same problem. What happened is that we caused a breaking change