Integration Testing, Part 1

Integration tests are the tests we use to validate that 2 or more software modules work together. 

Let me give an example by analogy.  Suppose you have a car engine and you know it works (for whatever definition of "work" you want to use).  I have a muffler, and it also works, again, using whatever definition of "works" you want to use.

Now suppose you are asked "Will the engine you make work with my muffler?"

Each component works, but how can we tell if they will work together?

Integration testing is the key here.  We know that each component works by itself, but there are no guarantees that they will work together.

For instance, one test case will be that the size of the hole for the exhaust from the engine is the same size as the muffler pipe (to speak broadly).  If the engine has a 5 inch exhaust and the muffler is only 3 inches wide, we have a mismatch and they won't work together.

A second case, assuming the first passes, is connecting the 2 components.  Even if the size of the exhaust is correct, if you use metric bolts and I don't, we are in a failing state again.

In fact, there will be many more test cases for this.  Materials construction (some metals don't interact well with others), weight considerations, stress cases (handling backfiring, for instance) and many, many more. 

The same mentality applies to software testing and I will go deeper into that next time.

Until then, questions, comments, concerns and criticisms always welcome,

John

Updating some data about our data for our team

One of the techniques we use to develop new features (which I cannot talk about) is wrapping the new code behind what we call a Feature Flag.  A feature flag is just a variable that we set OFF while we are working on features to keep that code from running until we are ready to turn it ON.  This is relatively basic engineering and there really is not anything special about it.

As a related note, many Windows applications use a registry key to turn features on or off.  We use a text file here with other data about the flag stored in it. For example, we not only store the name of the flag, but the name of the team that owns it, a short description of what it is for and when we expect to be done.

In some cases, those dates can be wrong or the name of the flag needs to be changed to make its purpose more clear.  For instance, imagine this contrived example. A flag named "tooltip" is not all that useful, but a flag named "ShowAdvancedAnalyticsTooltipsForTheWebClients" is a bit more explanatory.  And if work finishes early or lags behind estimated dates, those dates can change as well.

So this week I expect to update these values (metadata) for our flags.  This is very low priority work but with US holidays approaching, now seems like the best time to get this knocked off the to do list.

Questions, comments, concerns and criticisms always welcome,

John