Jump to Start Test-Driven Database Development (TDDD) – Part 1

The most common approach to developing database solutions is to start creating database objects based on business requirements which is also known as “Conventional Database Development”.

In this article, we are going to explore the implementation of such approaches as conventional database development and test-driven database development on the particular examples.

To begin with, have a closer look at the conventional database development.

Read More

Replacement of Algorithm Testing with Testing of Effects Being Inserted

As I expected, Rule 8 from the article “Rules for Implementing TDD in Old Project” stating that we don’t need to test the algorithm of methods raised many “how” and “why” questions. When writing the previous article, it seemed obvious to me, so I did not go into much details on the matter. In this article, I provide a small sample code and two examples of how it could be tested.

Read More

Rules for Implementing TDD in Old Project

The article “Sliding Responsibility of the Repository Pattern” raised several questions, which are very difficult to answer. Do we need a repository if the complete disregard of technical details is impossible? How complex must the repository be so that its addition can be regarded worth-while? The answer to these questions varies depending on the emphasis placed in the development of systems. Probably the most difficult question is the following: do you even need a repository? The problem of “flowing abstraction” and the growing complexity of coding with an increase in the level of abstraction do not allow to find a solution that would satisfy both sides of the fence. For example, in reporting, intention design leads to the creation of a large number of methods for each filter and sorting, and a generic solution creates a large coding overhead.

Read More