1 Jul 2014

1 Jul 2014

Test Driven Development in Agile BI – “Fake it till you make it”


Category: News, White Paper

Test Driven Development in Agile BI – “Fake it till you make it”


The Agile methodology shift in the last few years has affected the development lifecycle, and therefore the testing process as well. The concept is to work in short development cycles and to start the development by writing a test case that defines the expected functionality. The test itself will of course fail at first, and accompany the developer during the development process. Therefore, each development process is a cyclic process guided by the concept “Fake it till you make it”. Work according to the steps in a cyclic process.

  1. Create a test – the test will fail until the desired functionality will work. The test should be driven by the business requirement and expected result.
  2. Run all tests and validate the new test failure.
  3. Start your core development until it meets tests logic and tests run successfully. At this point code can be “dirty” and the target is passing the tests.
  4. Clean your code to final result, location, etc…
  5. Run all tests
  6. Repeat all steps if necessary.


Test Driven Development supports working in small units of coding which usually relates to a group of functions.  This methodology is very clear in the software world, but adoption to the BI world is sometimes fuzzy. Working by the methodology reduces debugging and QA time – done during the development and reduces “surprises” at the delivery or acceptance tests. As a result the risk level of the delivery also decreases.

In the BI world the unit will usually be a model or a logical part of a model, and can be backend feature in the DWH, or a frontend feature like a report or a dashboard.

How to implement “Fake it till you make it” concept in BI environments using QualityGates?

  1. Create the test scenario and the test itself using QualityGates wizards.
  2. Start development – quick and dirty, at this phase you can isolate new logic/ piece of code from your final ETL process. Code should meet the test logic, which means it can be written to answer the final result records/report/dashboard.
  3. Run tests during the cycle – at this phase you will validate that the new logic meets new tests, and that the other tests pass successfully – this means that there is no regression for other parts of the code/other processes. If any regression occurs you will catch it at an early stage. Quality Gates Regression testing can include running tests on other logical parts of the model, or by comparing final result set between versions (can be done for the database versions or for reports and dashboard versions) using one of the comparing tests of Quality Gates.
  4. Repeat as necessary. In case you find yourself that the piece you developed is not testable, try again or redeveloped so your development can be tested – this is what test driven development is all about…

How to test complex logic without duplicating it in the test logic again?

The guiding principle is keep it simple as you can – focus on final result.

Add fake records to your data, these records can track you along all steps of the process till final result. Because you created the records yourself – you will know what is the final desired result or threshold. Quality Gates will enable you to create an execution flow that will create the fake records and relate to them at your test. You will also be able to combine the test in your external processing process in any processing tool (ETL tools, Qlikview, SAP loading, etc…).

This method will cover the logic testing by 90% – it will not cover special scenarios that will surprise you in data, but you can cover that in additional other tests (like totals, accumulative thresholds according to business standards, etc…). When performing logic duplication in the test, you are actually duplicating your logic bug into the test, and will not help you validate the code.