Monthly Archives: December 2014

“Sending a probe”: alternative to stubs, mocks and service virtualization

Picard: Data, prepare a class one probe. Set sensors for maximum scan. I want every meter of Nelvana Three monitored. –  Star Trek The Next Generation, The Defector

Stubs – “used commonly as placeholders for implementation of a known interface, where the interface is finalized/known but the implementation is not yet known/finalized.”

Mock objects – “are simulated objects that mimic the behavior of real objects in controlled ways”

Service virtualization – “emulates only the behavior of the specific dependent components that developers or testers need to exercise in order to complete their end-to-end transactions. Rather than virtualizing entire systems, it virtualizes only specific slices of dependent behavior critical to the execution of development and testing tasks.”

NEW  – “Probe” –   An isolated feature/set of features (not just a mimic!) of a system, enhanced with testing support: flexible, configurable data and commands input  and enhanced evaluation/validation output.. Could be used for early integration tests for reducing risks and provide useful feedback. The probe can simulate different scenarios of using a “real”  feature sent in the remote environment and can send back useful feedback. The usage (and the integration) it is simulated and not the functionality!

The probe could be designed to integrate with other systems or to be standalone and just “explore” the environment (that rather mean integration with infrastructure systems) Stand alone probes, if are carefully used, can gather data also from production environment, without interfering with real applications and functionality.

Simple examples:

  • send a probe with the logging related feature, if for example the logging should use remote unavailable web (or others) services (available only in the integration environment and not available remote)
  • send a probe with a feature that send emails in integration environment specific context

Example with stubs, mocks and service virtualization


  • we need to integrate our system, that shall contain features from A to L, with an external system
  • when features sets ABC and EFG will be ready, we want to start integration test and we will use stubs and mocks for features J and K, and service virtualization for feature L

Example with probes

ProbeFrom practical experience, I can tell that using “probes” you can get flexibility similar with unit testing in the integration environment, and for integration tests.


  • we need to make some very early integration tests only for feature A (that it is realized also very early) because it is important and its integration suppose high risks and high incertitude
  • we will “send” the feature A realization in the integration environment and we will get a much feedback it is possible. For this purpose, feature A it is “decorated” with some facilities for: accepting flexible inputs, enhanced outputs/feedback, with others for adapt, if is necessary, to some external system and possible others stuff
  • we can run more test scenarios for feature A in target integration environment and gather the useful feedback
  • important: it is easier to change the probe specific decorations and to get quickly more other feedback then re-deploying more features together with too many needed stubs/mocks or services virtualizations.

The main trick it is the decoupling: we are isolating the test of <Feature A, Integration environment> with the benefits of getting from “decorations” more flexibility on tests (scenarios, input data) and a larger feedback channel. If the text context it is <Features A-B-C-D, Integration environment> we do not have these benefits for one single feature. The effort for building and using test cases with different usage scenarios and input data for only one feature it is much bigger in the last case.


  • “probe” testings are exploratory integration tests, for discovering problems or for investigating risks
  • “probe” based testing cannot be done if the design is not based on separation of concerns, SRP decoupling, functional cohesion and other similar  design principles.

One of the main concerns for Agile Architecture and Agile at scale is to perform the integration tests first / integration tests early. “Probe” based integration offer a flexible, opportunistic approach that could be included also in the spike solution category from XP.

Picard: Oh, it’s me, isn’t it? I’m the someone. I’m the one it finds! That’s what this launching is, a probe that finds me in the future. – “Star Trek: The Next Generation”, The Inner Light

A product it is … not a product.

What does MVP really mean…? (MVP – Minimal Viable Product)

That is a very interesting question. A first idea is to thing to the customer business needs: what are the minimal set of features that are needed and have relevance to be deployed first.
In fact, with this first delivery, we are initiating an ecosystem, where:

  • a business relationship with the customer(s) it is born, where the development side mus be able to follow the customer needs on short, medium and long term with good enough cost, quality, responsiveness and other possible attributes
  • the economics of this business relationship must be good enough for both sides
  • the development side must be able to find continuously effective and efficient technical solutions
  • the development side must form and maintain a product team with enough skills, maturity and availability to serve the customer needs
  • the process approach must make sure that enough business side feedback it is included in the product in order to make this product fit for the target business. Also the product must have such properties and included support in order to be  a consumable solution (DAD – Disciplined Agile Delivery concept)
  • the initiated approach must produce repeatable results (DAD principle)


A Minimum Viable Product it is in fact a Minimum Viable Product Ecosystem that could include:

  • Minimum Viable Consumable Product
  • Minimum Viable Product Economics
  • Minimum Viable Product Architecture / Design approach
  • Minimum Viable Team
  • Minimum Viable Process

It is not a product …. it is an endeavor, an enterprise, an initiated path to follow, a vision.

… yes, you first need some opportunities in the market, but you can blow up any opportunity without  considering above mentioned aspects.

A product is not …. (just) a product, it is an ecosystem that need to born, adapt and survive.

%d bloggers like this: