Mitigating Incomplete Dependencies

    09 September 2014

    As a consultant, I frequently encounter projects where assumed dependencies are not in place before the beginning of the project. Sometimes, these items might not even be available for months after I am expected to finish and leave. This is especial true of anything related to data (e.g. data services, data access libraries, databases, and sample data). But, it could also be related to non-functional requirements such as authentication and logging frameworks. Despite this, even when estimates were based on these items being ready and the customer knowingly signed off on those assumptions, customers have a hard time understanding the impact to the project schedule and will often argue not to move the target release date. I am not advocating that your team should give in to these unreasonable demands. In fact, I would argue the opposite. However, whether you are waiting on dependencies that should have been completed or had planned to work in parallel from the start, I do recommend architecting your application in such a way as to minimize the damage caused by incomplete dependencies.

    Setter Injection

    12 August 2014

    In my last post, I explained some of the differences between Dependency Injection (DI) and the factory pattern. I also gave an example of how constructor injection could be used to leverage the DI framework's ability to manage dependencies of dependencies. While constructor injection is my personal preferred way of doing it, there is an alternative. You could also use setter injection.

    Factories and Dependency Injectors

    14 July 2014

    It seems that over the years, many people have accepted that Dependency Injection (DI), which is sometimes called Inversion of Control (IoC), is a "good thing" and that they should be "doing it." But, few of those that I talk to seem to know why that is. And, fewer still can tell you the difference between the Factory Pattern and DI. This is usually an indicator of how they (mis)utilize their DI framework. Many of the implementations that I have seen use it as a glorified factory. But, DI is a special implementation of the factory pattern that can do so many more things to help improve the structure of your code and improve testability than just serving out objects. The relationship between the factory pattern and DI is like the relationship between rectangles and squares. All squares are rectangles, but a rectangle is not necessarily a square. Just like all DI frameworks follow the factory pattern, but a factory is not necessarily a DI container.

    ETL Testing Basics

    12 September 2009

    When doing developer testing outside of the database, it is always a good idea to start with simple unit tests that stub or mock any dependencies. If your test calls a method that calls other objects, a database, a service, etc., then you have entered the realm of integration tests. Integration tests are much harder to design, setup, and maintain. Unfortunately, when you start testing an ETL process, you are going to have to test the end-to-end integration of multiple databases. This makes an already difficult problem exponentially more difficult. For starters, your data needs to start in an expected state, and there can only be one test running against the database(s) at a given time or the data will be corrupted. To make the testing of ETL processes more manageable, this article introduces some general concepts that should be followed.