I have just posted The Math Function Unit Testing Design Pattern on my GitHub blog.
Here is the introduction…
This article provides an overview of a new design pattern for unit testing in any programming language, ‘The Math Function Unit Testing Design Pattern’. The data-driven design pattern involves repeatable, automated testing, and minimises unit test code (see example) by delegating to library modules the unit test driver, reading/writing of test data and assertion and formatting of results.
After a section on the background, the article describes the design pattern in two parts: the first deals with the concepts of transactions and APIs and why we should base our unit testing around APIs, while the second describes the design pattern at high level.
Wrapper Function – Purely_Wrap_All_Nets
Go to source location
Here is the complete function:
FUNCTION Purely_Wrap_All_Nets( p_inp_3lis L3_chr_arr) -- input list of lists (group, record, field) RETURN L2_chr_arr IS -- output list of lists (group, record) l_act_2lis L2_chr_arr := L2_chr_arr(); l_csr SYS_REFCURSOR; BEGIN FOR i IN 1..p_inp_3lis(1).COUNT LOOP INSERT INTO network_links VALUES (p_inp_3lis(1)(i)(1), p_inp_3lis(1)(i)(2), p_inp_3lis(1)(i)(3)); END LOOP; l_act_2lis.EXTEND; OPEN l_csr FOR SELECT * FROM TABLE(Net_Pipe.All_Nets); l_act_2lis(1) := Utils.Cursor_To_List(x_csr => l_csr); ROLLBACK; RETURN l_act_2lis; END Purely_Wrap_All_Nets;
This is a good example of how little code may be necessary when following The Math Function Unit Testing Design Pattern: The complexity of the code reflects only the complexity of the external interface. Here, there are single input and output groups, and so the code is equally simple, despite the unit under test having a larger degree of internal complexity.