I’ve spent a decent amount of time for my day job creating a tool to generate unit\/component test skeletons from existing source code. I’ve made reasonable progress in the last couple of weeks.<\/p>\n
Background… this isn’t the first time I’ve run into code without unit tests. Any of us that’ve had to deal with legacy code have found small to large chunks of code with no unit tests. I think of this as flying blind from a development perspective. It’s generally impossible for integration testing and software validation to find all problems. This is of course true of unit tests as well, but unit tests can find issues that other testing cannot, and ideally before code is committed to a repository.<\/p>\n
At any rate, the point of my tool is to speed up the creation of unit tests for legacy code that doesn’t have any unit tests written.<\/p>\n
The first pass was relatively easy after finding my way around the libclangTooling APIs. Generating skeletons from a blank slate (no existing tests) is easy.<\/p>\n
I did get hung up for a bit with an existing pattern from a tool we already had. That pattern combined the code to be tested with the unit tests in a single translation unit. It turns out that this complicates things significantly if you really want to produce test code that compiles without intervention in most cases. I’ve since decided that it’s smarter to produce a translation unit that #includes the code to be tested. This accomplishes the main purpose of the previous pattern (bring module-static variables into scope) without touching the code under test. This separates the concerns of unit tests versus original source code, so there are no questions about whether or not the original source code matches what is being tested: by #including it, it is unquestionably unmodified. Yes, it’s unconventional to #include a .c or<\/p>\n
The hard part came when I decided that I needed to be able to automatically update the unit test code. This is basically a sanity check sort of thing… if someone adds a new function to a translation unit and doesn’t write a test for the new function, at a minimum I want my tool to warn me. Better, it should generate a new unit test that fails until someone populates it, and should call it from main() in the test driver so that no one will miss the fact that there’s a failing unit test.<\/p>\n
Conversely, the tool should warn about tests for functions that no longer exist and hence have unit test functions that will not compile and link. Or better, delete the unit test for the function that no longer exists.<\/p>\n
I’m now doing both of these things. I add new unit test skeletons that don’t exist, while leaving the existing ones alone. I remove unit tests for functions that have disappeared.<\/p>\n
I wound up doing this with 2 separate passes of ClangTool::run(), each using a different class derived from ASTFrontendAction and processing different files. The first pass processes the code under test, the second pass processes the unit test code.<\/p>\n
So far so good with respect to functions under test and unit test functions. I now need to to the same for the extern global variables and stub functions that I generate as part of the first pass.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve spent a decent amount of time for my day job creating a tool to generate unit\/component test skeletons from existing source code. I’ve made reasonable progress in the last couple of weeks. Background… this isn’t the first time I’ve run into code without unit tests. Any of us that’ve had to deal with legacy … <\/p>\n