Unit Testing Design Evolution in an Agile Project: The Pecan Case Study, Slides of Computers and Information technologies

Download Unit Testing Design Evolution in an Agile Project: The Pecan Case Study and more Slides Computers and Information technologies in PDF only on Docsity!

Case Study: Unit Testing for Pecan

Ian Holyer Ian Holyer

The project

• This case study describes a snapshot of a project inThis case study describes a snapshot of a project in progress, focussing just on the design of the testing progress, focussing just on the design of the testing
• The project is called pecan, and the snapshot of theThe project is called pecan, and the snapshot of the source code is available on the course web site source code is available on the course web site
• The project involves developing a parser and scannerThe project involves developing a parser and scanner generator, a bit like ANTLR but following KISS generator, a bit like ANTLR but following KISS
• The project is essentially a compiler for a grammarThe project is essentially a compiler for a grammar language, generating (say) Java at the end language, generating (say) Java at the end
• My own personal preference for unit testing is DIY, forMy own personal preference for unit testing is DIY, for maximum flexibility and customisation, and so that the maximum flexibility and customisation, and so that the design of the testing can evolve with the project design of the testing can evolve with the project

First testing design

• As usual, I started with the simplest testing design,As usual, I started with the simplest testing design, where tests are built into a main method in each class where tests are built into a main method in each class
• Since I was testing compiler passes, each test couldSince I was testing compiler passes, each test could consist of an input string and expected output string consist of an input string and expected output string
• As the project grew, some of the strings got longAs the project grew, some of the strings got long
• Writing multi-line strings inside the Java code becameWriting multi-line strings inside the Java code became tedious and space-consuming tedious and space-consuming
• It was time to move the tests out of the classesIt was time to move the tests out of the classes

Second testing design

• Each class e.g. Parser.java now had a companion testEach class e.g. Parser.java now had a companion test file parser.txt with tests in file parser.txt with tests in
• It seemed easier to manage the tests in one file, ratherIt seemed easier to manage the tests in one file, rather than lots of little files than lots of little files
• Each test had input text, a line of - signs, and expectedEach test had input text, a line of - signs, and expected output, and tests were separated by a line of = signs output, and tests were separated by a line of = signs
• The code for chopping up and running the tests wasThe code for chopping up and running the tests was repeated in each class, so this code was separated out repeated in each class, so this code was separated out into a utility class Test.java into a utility class Test.java

Specification of tests

• The tests are still separated by lines of = signsThe tests are still separated by lines of = signs
• Each test now needs a first line which specifies whichEach test now needs a first line which specifies which class to test, and gives a test name and description class to test, and gives a test name and description Parser R1 One rule Parser R1 One rule x = "a" x = "a" ---------- ---------- GRAMMAR GRAMMAR RULE RULE ID ID xx STRING STRING "a""a" ========== ========== ... ...

Specification of Test.java

• We want to be able to typeWe want to be able to type java pecan.Test Parser R1 java pecan.Test Parser R java pecan.Test Parser java pecan.Test Parser java pecan.Test java pecan.Test
• The first runs one test (so that we can repeat a brokenThe first runs one test (so that we can repeat a broken test in isolation while debugging it) test in isolation while debugging it)
• The second runs all the tests on one class, when otherThe second runs all the tests on one class, when other classes may be broken at the time due to refactoring! classes may be broken at the time due to refactoring!
• The third runs all the tests on all the classesThe third runs all the tests on all the classes

Implementation

• The code for finding and calling the test method byThe code for finding and calling the test method by reflection is: reflection is: String cn = String cn = findClassName(); // eg "Parser"findClassName(); // eg "Parser" String in = String in = findTestInput();findTestInput(); Class Class c = Class.forName("pecan."c = Class.forName("pecan." + cn);+ cn); Method method = Method method = c.getDeclaredMethod("test", c.getDeclaredMethod("test", String.class);String.class); String output = String output = (String) method.invoke(null, (String) method.invoke(null, in);in);

Generic Testing

• The testing design I have used is very nearly generic,The testing design I have used is very nearly generic, and can easily be carried over into other projects and can easily be carried over into other projects
• The package name is specific and would needThe package name is specific and would need changing changing
• The tests are all very simple – string input and output,The tests are all very simple – string input and output, a bit more flexibility is needed a bit more flexibility is needed
• In a different project, you would still want the inputIn a different project, you would still want the input and output to be strings, so that the tests could be and output to be strings, so that the tests could be stored in a file, but you would want an extra “type” stored in a file, but you would want an extra “type” argument to the test method to trigger the testing of argument to the test method to trigger the testing of different methods different methods