DaedTech

Stories about Software

By

Unit Testing: Basics and Best Practices

Editorial Note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, have a look at their tools to help you track down and fix production issues.

A couple of year ago, I wrote a book about unit testing.  Now, I didn’t just sit down one day and decide to do it, and no big publisher commissioned me to do it.  The book started from humbler origins and grew somewhat organically.

It started as a series of presentations I did for groups new to the practice.  With more feedback and requests, it then grew into a blog post series and longer presentations.  Eventually, due to even wider demand, I made it into a book.

What was it that made this particular content so appealing, when no shortage of authors address this topic?  I feel pretty confident that it was the lead into the topic.  “You still don’t know how to unit test, and your secret is safe with me.”

When I started in this industry, only an avant garde fringe wrote automated tests for their code.  Over the last 15 years, however, that number has exploded, and the practice has become mainstream.  But “mainstream” does not mean “universal.”  Plenty of folks still do not have comfort with, or even exposure to the practice.  And yet, a form of peer pressure causes them to play that close to the vest.

So I reached out to these folks to say, “hey, no worries.  You can learn, and you don’t even have to climb too steep of a hill.”  I’d like to revisit that approach again, here, today, and in the form of a blog post.

Let’s get started with unit testing in C#, assuming that you know absolutely nothing about it.

Read More

By

How You’re Probably Misunderstanding TDD

Editorial note: I originally wrote this post for the TechTown blog.  You can check out the original here, at their site.  While you’re there, take a look around at their training courses.  

Let’s get something out of the way right up front.  You might have extensive experience with test driven development (TDD).  You might even practice it routinely and wear the red-green-refactor cadence like a comfortable work glove.  For all I know, you could be a bonafide TDD expert.

If any of that describes you, then you probably don’t actually misunderstand TDD.  Not surprisingly, people that become adept with it, live, and breathe it tend to get it.  But if that introductory paragraph doesn’t describe you, then you probably have some misconceptions.

I earn my living doing a combination of training and consulting.  This affords me the opportunity to visit a lot of shops and talk to a lot of people.  And during the course of these visits and talks, I’ve noticed an interesting phenomenon.  Ask people why they choose not to use TDD, and you rarely hear a frank, “I haven’t learned how.”

Instead, you tend to hear dismissals of the practice.  And these dismissals generally arise not from practiced familiarity, but from misunderstanding TDD.  While I can’t discount the possibility, I can say that I’ve never personally witnessed someone demonstrate an expert understanding of the practice while also dismissing its value.  Rather, they base the dismissal on misconception.

So if you’ve decided up-front that TDD isn’t for you, first be sure you’re not falling victim to one of these misunderstandings.

Read More

By

How to Write Test Cases

Editorial note: I originally this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, check out Stackify’s APM offering.

As I’ve mentioned before on this blog, I have a good bit of experience writing unit tests.  In fact, I’ve managed to parlay this experience into a nice chunk of my living.  This includes consulting, training developers, building courses, and writing books.  From this evidence, one might conclude that unit testing is in demand.

Because of the demand and driving interest, I find myself at many companies, explaining the particulars of testing to many different people.  We’d like some of testing magic here, please.  Help us boost our quality.

A great deal of earnest interest in the topic lays the groundwork for improvement.  But it also lays the groundwork for confusion.  When large groups of people set out to learn new things, buzzwords can get tossed around and meaning lost.

Against this backdrop, I can recall several different people at asking, “how should we/our people write good test cases?”  If you’re familiar with the terms at play more precisely, you might scratch your head at this question given my unit testing expertise.  A company brought me in to teach developers to write automated unit testing and someone is asking me a term loosely associated the QA group.  What gives?

But in fact, this really just begs the question, “what is a test case?”  And why might it vary depending on who writes it and how?

Read More

By

If You Automate Your Tests, Automate Your Code Review

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look at CodeIt.Right.

For years, I can remember fighting the good fight for unit testing.  When I started that fight, I understood a simple premise.  We, as programmers, automate things.  So, why not automate testing?

Of all things, a grad school course in software engineering introduced me to the concept back in 2005.  It hooked me immediately, and I began applying the lessons to my work at the time.  A few years and a new job later, I came to a group that had not yet discovered the wonders of automated testing.  No worries, I figured, I can introduce the concept!

Except, it turns out that people stuck in their ways kind of like those ways.  Imagine my surprise to discover that people turned up their nose at the practice.  Over the course of time, I learned to plead my case, both in technical and business terms.  But it often felt like wading upstream against a fast moving current.

Years later, I have fought that fight over and over again.  In fact, I’ve produced training materials, courses, videos, blog posts, and books on the subject.  I’ve brought people around to see the benefits and then subsequently realize those benefits following adoption.  This has brought me satisfaction.

But I don’t do this in a vacuum.  The industry as a whole has followed the same trajectory, using the same logic.  I count myself just another advocate among a euphony of voices.  And so our profession  has generally come to accept unit testing as a vital tool.

Widespread Acceptance of Automated Regression Tests

In fact, I might go so far as to call acceptance and adoption quite widespread.  This figure only increases if you include shops that totally mean to and will definitely get around to it like sometime in the next six months or something.  In other words, if you count both shops that have adopted the practice and shops that feel as though they should, acceptance figures certainly span a plurality.

Major enterprises bring me in to help them teach their developers to do it.  Still other companies consult and ask questions about it.  Just about everyone wants to understand how to realize the unit testing value proposition of higher quality, more stability, and fewer bugs.

This takes a simple form.  We talk about unit testing and other forms of testing, and sometimes this may blur the lines.  But let’s get specific here.  A holistic testing strategy includes tests at a variety of granularities.  These comprise what some call “the test pyramid.”  Unit tests address individual components (e.g. classes), while service tests drive at the way the components of your application work together.  GUI tests, the least granular of all, exercise the whole thing.

Taken together, these comprise your regression test suite.  It stands against the category of bugs known as “regressions,” or defects where something that used to work stops working.  For a parallel example in the “real world” think of the warning lights on your car’s dashboard.  “Low battery” light comes on because the battery, which used to work, has stopped working.

Read More

By

Habits that Pay Off for Programmers

Editorial Note: I originally wrote this post for the LogEntries blog.

I would like to clarify something immediately with this post.  Its title does not contain the number 7, nor does it talk about effectiveness.  That was intentional.  I have no interest in trying to piggy-back on Stephen Covey’s book title to earn clicks, which would make this post a dime a dozen.

In fact, a google search of “good habits for programmers” yields just such an appropriation, and it also yields exactly the sorts of articles and posts that you might expect.  They have some number and they talk about what makes programmers good at programming.

But I’d like to focus on a slightly different angle today.  Rather than talk about what makes people better at programming, I’d like to talk about what makes programmers more marketable.  When I say, “habits that pay off,” I mean it literally.

Don’t get me wrong.  Becoming better at programming will certainly correlate with making more money as a programmer.  But this improvement can eventually suffer from diminishing marginal returns.  I’m talking today about practices that will yield the most bang for the buck when it comes time to ask for a raise or seek a new gig.

Read More