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

An Introduction to the Types of Cloud Computing

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look around at some of their other authors and content.

The folks at Gartner have something awesome called the “hype cycle”.  The cycle contains a “peak of inflated expectations” and a “trough of disillusionment”.  So, that alone gives it a pretty significant amusement factor.

But beyond the amusement lies an important insight into our collective psychology.  Those of us working in tech work in a booming and constantly evolving industry.  Because of this, we find ourselves bombarded with buzzwords.  These generate excitement at first and disillusionment later.  Eventually, they reach equilibrium.

Gartner uses this set of observations to advise companies about risk.  But we can use it to identify a term’s likelihood to induce buzzword fatigue and produce derisive satire.

Let’s get specific.  Do you remember a few years back, when “X as a service” really took off?  The world seized on the promise of the cloud.  Don’t maintain it yourself — have a service do it!  As the term rocketed up the peak of inflated expectations, everyone wanted a part of the cloud.

But then it fell into the trough of disillusionment, and satire ensued.  Twitter accounts offered “sarcasm as a service” to poke fun at the hype.  If you saw an offering for “everything as a service,” you had no idea whether it was serious.

Since this time, however, these offerings have ascended the so-called “slope of enlightenment” and established themselves as mainstream.  Actually, let me correct that.  They have established themselves as foundational to the modern internet.

Let’s now unpack this X as a service concept a bit.  In order to do that, I’ll offer a story in contrasts.

The “As a Service” Concept

Imagine that I own a small business.  In this capacity, I want to keep track of prospects, leads, and customers for sales purposes.  You can think of this as “customer relationship management” (CRM) software.

Back in the early days of my career (late 90s, early 2000s), you might have done this with Excel.  At least, you would have used Excel until it became too unwieldy.  Then, you’d have gone to Best Buy and purchased software that you installed from a CD.  Finally, you’d have installed the “client” on anyone’s PC who needed to use it while installing the “server” on some jack of all trades machine running Windows 2000 or something.  From there, using it was as easy as making sure not too many people tried to change things at once.

Fast forward a couple of decades and that seems… odd.  These days, you’d probably just navigate to something like salesforce.com and create a trial account.  Certainly small business owners would take this approach.  Larger organizations with more privacy concerns might still setup servers and install their own software.  But even the ones doing this would probably host a web app and have “clients” access it via browser.

This tale drives at the essence of “as a service.”  Stuffed into that small phrase, you find the large, important concept of “let someone else worry about it.”  You shouldn’t need to think about clients, servers, networks, and the like to have a CRM system.  Let someone else worry about it.  You just want to sign in via the browser.

This concept has become so important and so ubiquitous that it drives today’s internet.  But not all cloud, “as a service” concepts are created equal.  Let’s take a look at the major types of cloud computing, by conceptual level.

Read More

By

A Look at 5 NoSQL Solutions

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at variety of monitoring solutions they offer to keep your production code running smoothly.

If you’ve never seen it, you should take a look at the Gartner “Hype Cycle.”  Technology changes the world quickly.  And the technology world itself changes even more quickly.  This can lead to breathless buzzword saturation, followed by the so-called “trough of disillusionment” when the tech predictably fails to cure world hunger.

Wired magazine put “Big Data” in the trough of disillusionment in 2013.  So that placed it at the peak of inflated expectations around 2011.  And, as a matter of fact, I remember that time quite well.

Everyone suddenly became interesting in something called “NoSQL.”  What was it?  What problems did it solve?  It didn’t matter — you just needed to start doing it.  And, given the year, you should start doing it in a way that somehow involved a mobile app.

What Is NoSQL?

Neither the big data movement nor NoSQL technologies have gone anywhere.  They’ve woven themselves seamlessly into the fabric of the tech world.  Only the hype has abated.

But that doesn’t mean everyone obtained perfect clarity about what this involved.  When a concept hits the peak of the hype wave, definitions get fuzzy and folks get confused.  If you don’t believe me, try to obtain universal consensus about what “agile” means.  NoSQL suffered the same fate.

You can read about some of those misconceptions here, but I’d like to focus on the one I recall as most prominent from my experience.  Specifically, many people and particularly relational database traditionalists, seemed to believe “NoSQL” was some kind of off-brand comptetitor to traditional databases.  That is, you could go with Oracle, SQL Server, or NoSQL.

I highlight that misconception to underscore the counterpoint.  I’ve seen a few different suggested meanings of the acronym, but I favor “Not Only SQL.”  Simply put, the NoSQL movement represented the idea that there were other options for storing data besides relational databases.

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

Learning with Hands on Projects

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, take a look around and download NDepend to try it out.

If you want a surefire way to make money, look for enormous disparity between demand and supply.  As software developers, we understand this implicitly.  When we open our inboxes in the morning, we see vacuous missives from recruiters.  “Hey, dudebro, we need a JavaScript ninja-rockstar like you!”

You don’t tend to see vaguely patronizing, unflinchingly desperate requests like that unless you sit on some kind of goldmine.  They approach us the way one might approach a mischevious toddler holding a winning lottery ticket.  And, of course, anyone would expect that with wildly disproportionate supply and demand.

But, for us, this transcends just writing the code and oozes into learning about it.  Like baseball teams playing the long game, companies would rather grow their own talent than shell out for high-priced free agents.  And so learning about software might just prove more of a growth industry than writing it.

Look at wildly successful industry player Pluralsight.  It has built a benevolent commercial empire on the simple promise of democratized learning about technical pursuits.  Then you have a host of fast followers, an army of boot camp providers, and endless how-to blogs.  Sometimes it seem as though a gigantic wave of pressure pushes us all toward writing a bit of code.

The Learning Tools in Your Tool Belt

Let’s say that you’re convinced.  You see the money to be made, or you simply feel drawn to the profession.  You want to get involved, but don’t quite know where to start.  What sorts of learning can developers avail themselves of?

While I won’t call this an exhaustive list, I can offer some general categories of learning.  First, consider theoretical, passive learning.  You crack open some book called, “Principles of Modern Web Development” and get to reading.  Second, you have classroom-style learning.  An instructor leads your lessons, curates information, and engages you in Q&A.  And, third, you have hands on learning.  With this kind of learning, you put actual concepts into practice.

Understand that I do not consider these mutually exclusive by any means.  Any serious leaning plan worth its salt is going to incorporate elements of all of these (and probably other form categories that escape me at the moment).  But understanding the flavors will inform the rest of this post.

Read More