user experience
We programmers are obsessive by nature. But I often get frustrated with the depth of our obsession over things like code coverage. Unit testing and code coverage are good things. But perfectly executed code coverage doesn’t mean users will use your program. Or that it’s even worth using
unit testing
Let’s say you’re about to deploy an application. Said app has been heavily tested by your development team, who have all been infected by unit testing fever. It’s also been vetted by your QA group, who spent months spelunking into every crevice of the app. You even
unit testing
J. Timothy King has a nice piece on the twelve benefits of writing unit tests first. Unfortunately, he seriously undermines his message by ending with this: However, if you are one of the [coders who won’t give up code-first], one of those curmudgeon coders who would rather be right
unit testing
Why does Wil Shipley, the author of Delicious Library, hate unit testing so much? I’ve certainly known companies that do “unit testing” and other crap they’ve read in books. Now, you can argue this point if you’d like, because I don’t have hard data; all I
nunit
After years of building ad-hoc test harnesses, I finally adopted formal unit testing on a recent project of mine using NUnit and TestRunner. It was gratifyingly simple to get my first unit tests up and running: <TestFixture()> _ Public Class UnitTests Private _TargetString As String Private _TargetData As Encryption.
programming languages
On Bruce Eckel’s Static vs. Dynamic [typing]: Despite this, I’ve had some leanings back in the direction of static type checking. As you point out, the goal is to create solid components – the question is how to accomplish that? In a dynamic language you have the flexibility to