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
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
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.
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
Udi Dahan writes about the fallacy of reuse. I couldn’t agree more. In my previous job, reuse was a selling point to our clients. We promised that building the current system will produce components that will help build the next system at a lower cost. A noble goal. Here’s what happened: we spent a lot
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.
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,
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
SecretGeek writes about examples on why people are not like computers. He gives 4, but I’m sure there are at least 7 differences. The first example DRY (Don’t repeat yourself) is the opposite of Horstman’s second law of management (from the excellent Manager Tools): “There’s no such thing as over-communication”. By the way the first
After doing some thinking, I decided to revive the blog. I’m still at Typemock, and you can find most of what I’ve blogged in the last year and a half there. I am going to cross-post from the Typemock blog, but also add some more “philosophical” stuff here. Stay tuned…