One of the great features of Sonarqube is that it gives visibility to your technical debt.
This importantly includes test coverage.
One could argue that without test coverage there isn’t as much value in looking at the issues that Sonarqube
reports as without tests, there are few guarantees that making changes to the code won’t introduce a regression issue.
So we have been working with teams on how to get tests for IIB.
Developers and testers can test a flow end to end, and it is valuable to collect that interaction as an automated test or integrated test.
But once you start generating test coverage, you start looking for the gaps.
Integration tests are valuable is that they are more closely aligned to user or systems needs, and the end interaction helps confirm requirements.
But they are hard to setup. So we’ve been helping teams with Unit testing.
The code below shows a hard to test version of the code.
To test this code, the Input and Output needs to setup and read, which is hard to do. It is also hard to have more then once test as they are more likely to interact and be more fragile.
/* Smaple ploject */ BROKER SCHEMA COBOLApplication CREATE COMPUTE MODULE OrderList2PurchaseData_Compute SET OutputRoot.DFDL.PurchaseData.InvoiceCount = InputRoot.DFDL.OrderList.InvoiceCount; DECLARE TotalQuantity INTEGER 0; DECLARE K INTEGER 1; WHILE K <= L DO SET OutputItem = THE ( IF OutputItem.ItemType = ’1′ THEN END IF; SET TotalQuantity = TotalQuantity + OutputItem.Quantity; SET I = I + 1; –Trailer IF EXISTS(InputRoot.DFDL.OrderList.PointOfSale1[]) THEN RETURN TRUE; CREATE PROCEDURE CopyMessageHeaders() BEGIN |
The refactoring tool takes this code and makes it more testable.
/* Smaple ploject */ BROKER SCHEMA COBOLApplication CREATE FUNCTION OrderList2PurchaseData_Compute_ProcessLogic(IN inputReference REFERENCE, IN outputReference REFERENCE, IN environmentReference REFERENCE) RETURNS BOOLEAN BEGIN SET outputReference.DFDL.PurchaseData.InvoiceCount = inputReference.DFDL.OrderList.InvoiceCount; DECLARE TotalQuantity INTEGER 0; DECLARE K INTEGER 1; WHILE K <= L DO SET OutputItem = THE ( IF OutputItem.ItemType = '1' THEN END IF; SET TotalQuantity = TotalQuantity + OutputItem.Quantity; SET I = I + 1; --Trailer IF EXISTS(inputReference.DFDL.OrderList.PointOfSale1[]) THEN RETURN TRUE; |
It also rebuilds the Main() so that the more testable code is callable.
CREATE COMPUTE MODULE OrderList2PurchaseData_Compute CREATE FUNCTION Main() RETURNS BOOLEAN BEGIN CALL CopyMessageHeaders(); DECLARE inputReference REFERENCE TO InputRoot; DECLARE logic_res BOOLEAN; RETURN logic_res; CREATE PROCEDURE CopyMessageHeaders() BEGIN END MODULE; |
It also creates a sample unit test that the developer can copy and extend.
CREATE PROCEDURE OrderList2PurchaseData_Compute_Test() BEGIN
– CREATE FIELD Environment.Test1; – DECLARE logic_res BOOLEAN; – if (outputReference.XMLNSC.Address.Postcode = ’2614′) THEN – DELETE FIELD Environment.Test1; END; |
Once the developer has some tests they will need to be able to trigger those tests.
The flow uses an MQ message to trigger the tests. The script running the tests then just to check the result message to see if it contains any “failure” messages.
We have uploaded a demonstration video which is available from our the tutorials page or is available here.