One of the earliest memories of my business intelligence career was learning how to test, specifically how to unit test. As a developer, this type of testing was my primary responsibility. The basic direction was to ensure business rules were being adhered to in the program and to document what I had tested. As a junior developer, this direction seemed simple enough, until I was alone at my PC. Then, the same set of common complaints, concerns, issues and questions that I hear from junior developers today hit me. This column lists the common extract, transform and load unit test concerns I encountered and offers solutions with an overall directive: there is no excuse for poor unit testing.

The time saved by lax or poor testing (unit or otherwise) ends up costing much more in bug fixes and redesign efforts the farther down the road the flaws are discovered. If you're reading this article as a junior developer, I hope you have a mentor teaching you these tips. If you're an experienced architect and/or mentor, are you still following these guidelines when you get your hands dirty in development? And are you passing these skills on to the next generation?

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access