It is already possible to use a XSLT transformation to filter the comparison context to a subset of pipes. However Ladybug will still always replay the entire report. This makes the test very brittle, as small changes to the underlying adapters can result in the stubbed messages to not work anymore after the changes. A simple change in the order of pipes often already breaks a test. Not using stubs mitigates this to some degree, but becomes unpractical with external calls.
With end-to-end kind of tests, this is not such an issue, because the amount of tests is usually very low and the scope of the test is very big, so they are quite easy to rerun and replace. With unit-tests this becomes an issue, because of the large amount of very precise and small test. The way it currently works makes unit-tests unfeasible, as each unit-test effectively has the maintenance cost of a big end-to-end test.
The smallest test scope currently possible is an entire adapter. A potential solution could be to maybe wrap the subset of pipes in a dummy adapter. That way I think no framework changes would be needed and only the subset of pipes are executed, because only those pipes are present in the dummy adapter. Another solution could be to tackle it from the other direction and introduce something in the framework to group a set of pipes similar to a function(read composite sender). That would allow for a smaller testable unit.
It is already possible to use a XSLT transformation to filter the comparison context to a subset of pipes. However Ladybug will still always replay the entire report. This makes the test very brittle, as small changes to the underlying adapters can result in the stubbed messages to not work anymore after the changes. A simple change in the order of pipes often already breaks a test. Not using stubs mitigates this to some degree, but becomes unpractical with external calls.
With end-to-end kind of tests, this is not such an issue, because the amount of tests is usually very low and the scope of the test is very big, so they are quite easy to rerun and replace. With unit-tests this becomes an issue, because of the large amount of very precise and small test. The way it currently works makes unit-tests unfeasible, as each unit-test effectively has the maintenance cost of a big end-to-end test.
The smallest test scope currently possible is an entire adapter. A potential solution could be to maybe wrap the subset of pipes in a dummy adapter. That way I think no framework changes would be needed and only the subset of pipes are executed, because only those pipes are present in the dummy adapter. Another solution could be to tackle it from the other direction and introduce something in the framework to group a set of pipes similar to a function(read composite sender). That would allow for a smaller testable unit.