This article is part of a series on common questions we discuss about building rule engine focused applications.
Changes to business rules in general can present day to day challenges as employees, customers, and other stakeholders adjust to the new way of making decisions. This is why it is so important to validate, test, and understand the overall impact to other business processes and other business rules before you deploy a change to or a new business rule.
For example, a lending institution may have a business rule, or a set of business rules that outlines how they value the FICO score (resulting in an adjusted FICO score) of a consumer applying for a new loan. In another project, this same value - the adjusted FICO score - may be used to determine loss mitigation plans for customers in default. How can the business know the impact of adjusting the business rule that determines the adjusted FICO score across all of their projects?
Unit Testing in Decisions
There are a number of ways - but one fundamental best practice and feature in Decisions is unit testing. Each business rule in Decisions can have any number of unit tests associated with it. For example - on any business rule that impacts the adjusted FICO score, you may have a series of unit tests that run the rule given certain inputs and compare the result to the expected result. Each of these unit tests could be informed by other projects that are using this business logic. While in those other projects you have unit tests on certain objects that check acceptable thresholds given certain inputs. When a unit test fails the system can notify a specified user or group of users so they can take action.
Designing these unit tests in parallel with your business rules is paramount in ensuring critical business logic is protected as changes are made - and those processes that consume critical business logic are change-tolerant through instant notification as the business logic evolves over time.
