Unit testing? Dev testing is a better term

The definition of what an unit is most often unclear and therefore unit testing more misunderstood. Martin Fowler in his blog Unit Test  states “It’s very ill-defined, and I see confusion can often occur when people think that it’s more tightly defined than it actually is “.

So let us use the term “Dev test” to state the early validation by developers during the development of code. What is expected of the code quality from developers? What should dev test uncover?  To setup a clear objective of what dev test should accomplish (objective), let us take a goal focused approach of as to what types of defects should be  uncovered at dev test.

“Quality Levels” – Defect types matter

Purposeful testing is about hypothesising potential type of defects and going after them.

Of course, as we one engages in this activity in the scientific manner, we revise and fine tune what to go after and how to go after.

Characterising the system under test as containing a “mixture” of various defect types, and inspired by fractional distillation as an efficient method of separation, Hypothesis-Based Immersive Session Testing (HyBIST)  sets up NINE quality levels of which the first FOUR are certain candidates for dev testing.

So what are the quality levels and  what is the purpose of tests at those levels?

Dev testing – What is the objective?

The objective of dev testing is that the building blocks of a system i.e. structural components are indeed clean enough to deliver the basic feature and worthy of integration to form the larger system. This means that a building block is internally   robust (structurally clean) and behaviourally correct (externally clean).

L1: Ensure bad inputs are rejected, about data types, values, boundaries
L2: Ensure that input interface is clean, about syntax(format), order, messages
L3: Ensure that internal structure is robust, about exception, resource handling, timing/sync, loops/iteration
L4: Ensure behaviour of feature is fine, about the business logic of the base technical feature
L5: Ensure behaviour of requirement/flow is fine, about the business logic of the requirement/flow that is a collection of technical features
L6: Ensure system works well is all different external environments and does not affect the environment
L7: Ensure that  key requirement/flow satisfies the expected attributes (e.g performance, volume…)
L8: Ensure that  final system deploys well in the real environment. Installation, configuration, migration are of interest here.
L9: Done by end users, the intention is ensure that it satisfies the actual end user’s intended needs and expectations.

So, what levels matter to the developer?

Quality levels denote a progression of quality as software is built. So as a developer, it is necessary to validate that basic behaviour of the building blocks that we build/modify. This means that a developer performs tests to ensure Levels 1-4 are satisfied, implying that the component is clean enough to integrate into the larger system. Additionally, if the component is critical to certain system attributes, then higher level tests beyond L5 could be useful to do.

DevTest need not be hard or painful, we have made it so. Oh, just automating unit tests does not help, well it is additional work, is it always needed? . The e-book below outlines a practical implementation of this and gives you a SmartDevChecklist as an aid to very rapidly perform DevTest. 

SaveSave