Debugging workflows
When dealing with complex data structures and dependencies between various data repositories Test Data Producers need all the help they can get from the Test Data Management tool during the implementation phase. In an agile testing environment, users should be able to debug data transformation workflows just-in-time and find data inconsistencies and bugs in a matter of minutes. This and much more comes with the new BizDataX Designer v3.2.
We significantly enhanced debugging support which is integrated within the Visual Studio debugger. Also, we enriched error messages with item processing information. That way, if an error occurs at the database layer, you get all the information about the item that caused it.
New debugging features include:
- Setting a debugger breakpoint on workflow activities applying data masking transformations
- Inspecting all item’s property values before and after a data masking transformation is applied at runtime
- Identifying the record which caused an underlying database exception
Figure 1: Debugging breakpoint set on ‘Pick first name from list’ data masking activity
Debugger breakpoint can be set on any workflow element which is a data masking transformation by setting the DebuggerBreak property as shown in Figure 1. Visual indicator analogous to the breakpoint symbol as used by Visual Studio is displayed just left of the activity display name.
Data masking transformations are activities which transform or replace the original value of an objects property or field according to a specific rule. In a real-world scenario rules can become highly complex and there is a merit in being able to observe the runtime value before and after a data masking transformation is applied.
Figure 2: Debugger breakpoint triggered at a point which enables item inspection
BizDataX package host application (i.e. the application executing your BizDataX package) exposes BreakBefore and BreakAfter methods which enable you to inspect the property or field value at runtime for each item being processed. Item being processed may represent a database record, a record in a CSV file or an item from some custom collection.
Item is visible through the standard Locals window as shown in Figure 2. Since most of our components operate on strongly-typed arguments, it is easy to discern its members.
Figure 3: Locals window highlights detected item property transformation
After the masking transformation (substitution with a random first name from our first names list) is applied on the property FirstName, value “Orlando” becomes “Étienne” as shown in Figure 3. Built-in Locals window functionality highlights the property value which changed.
Figure 4: Item which caused a database layer exception is displayed
Having information about the item which caused a database layer exception is helpful in troubleshooting the issue (see Figure 4). In cases where part of business logic is implemented through stored procedures or triggers, information about the affected records becomes a “must have”.