Test Driven Analysis

I mused over Test Driven Analysis on this blog before, but it was Richard Pugh’s talk on SAS to R Migration at LondonR last week that brought the topic back into my mind and clarified a few things.

Rich’s presentation focused on the challenge of how to ensure that the new system (R) would provide the same answers as the legacy system (SAS).

This is when it clicked with me: My brain is just another system as well. Suppose you have an idea for an analysis in your head. Taking that idea and transforming it into code is basically just the same as migrating code from one system to another system. Or, isn’t it?

Rich showed us how he does it: Start with the old code, write unit tests in the legacy system to confirm your understanding, re-write the unit tests in the new system and then start building the new analysis code in the new system.

Once he achieved that, he said, he would go backwards in forwards between the different pieces until he has enough confidence that the new system does what it supposed to do.

Test Driven Analysis is just that as well.

I start with an idea in my head, think about reasonable checks and following that I (should) write down unit tests and only then start writing the analysis code. Finally I go backwards and forwards until I have gained enough evidence and confidence to present my output and be able to defend it.

Test Driven Analysis

Citation

For attribution, please cite this work as:

Markus Gesmann (Apr 07, 2015) Test Driven Analysis. Retrieved from https://magesblog.com/post/2015-04-07-test-driven-analysis/

BibTeX citation:

@misc{ 2015-test-driven-analysis,
 author = { Markus Gesmann },
 title = { Test Driven Analysis },
 url = { https://magesblog.com/post/2015-04-07-test-driven-analysis/ },
 year = { 2015 }
 updated = { Apr 07, 2015 }
}

Related