DaedTech

Stories about Software

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

By

Secrets of Maintainable Codebases

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look at the tech debt quantification features of the new NDepend version.

You should write maintainable code.  I assume people have told you this, at some point.  The admonishment is as obligatory as it is vague.  So, I’m sure, when you heard this, you didn’t react effusively with, “oh, good idea — thanks!”

If you take to the internet, you won’t need to venture far to find essays, lists, and stack exchange questions on the subject.  As you can see, software developers frequently offer opinions on this particular topic.  And I present no exception; I have little doubt that you could find posts about this on my own blog.

So today, I’d like to take a different tack in talking about maintainable code.  Rather than discuss the code per se, I want to discuss the codebase as a whole.  What are the secrets to maintainable codebases?  What properties do they have, and what can you do to create these properties?

In my travels as a consultant, I see a so many codebases that it sometimes seems I’m watching a flip book show of code.  On top of that, I frequently find myself explaining concepts like the cost of code ownership, and regarding code as, for lack of a better term, inventory.  From the perspective of those paying the bills, maintainable code doesn’t mean “code developers like to work with” but rather “code that minimizes spend for future changes.”

Yes, that money includes developer labor.  But it also includes concerns like deployment effort, defect cycle time, universality of skills required, and plenty more.  Maintainable codebases mean easy, fast, risk-free, and cheap change.  Here are some characteristics in the field that I use when assessing this property.  Some of them may seem a bit off the beaten path.

Read More

By

Rethinking Assert with Shouldly

I was doing a bit of work with Tweetdeck open, when I noticed this tweet.

I’ve been using Assert.IsTrue() and its friends for years, so you might think I would take offense.  But instead, this struck me as an interesting and provocative statement.  I scanned through the conversation this started and it got me to thinking.

Over the years, I’ve evolved my unit tests heavily in the name of readability.  I’ve come to favor mocking frameworks on the basis of having fluent APIs and readable setup.  On a pointer from Steve Smith, I’ve adopted his philosophy and approach to naming unit test classes and tests.  My arrange and act inside of the tests have become highly readable and optimized for comprehension.

But then, there’s Assert.AreEqual.  Same as it ever was.

WorkHarder

Read More