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
From practical experience, I can tell that using “probes” you can get flexibility similar with unit testing in the integration environment, and for integration tests.
Description
- 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.
Warnings:
- “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
Agile Design = Adaptive-Lean Design 
The idea of the probe is interesting, but I’m missing an example to understand it better.
LikeLike
The idea of a probe is interesting, but I’m missing an example to understand how to apply it.
LikeLike
There are 2 “simple examples” in the text and are the ones that give me the idea for the first time.
We have an email sending feature, encapsulated in a product, that works well in the test and development and does not work in the production environment. I have extracted that feature, decorated with test adapters for test inputs and supplementary debug features. it was much more easy to make this “decoration” in the probe instead of the real feature “wired” in the product.
There is a full control of the inputs and a much better visibility of the outputs and intermediate steps. Changing the parameters and the inputs and analyzing much more debug information, we have used the “probe” with test data in the production environment: the problem was found very fast.
Same method was used in order to fix the integration issues for a login feature that use a specific API and software. That API was configured by a third party in a pre – production environment, and was not available in the test environment . We cannot fix the problem until we have sent a “probe” also decorated with possibilities for test inputs and enhanced logging features. In that way we could demonstrate that the problem was not in our product but in the configuration of third party software.
LikeLike