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

This article is a walk-through of creating a report base on a database object developed and tested by using test-driven development (TDDD). Furthermore, some tips for improving database unit testing via TDDD will be discussed in this article too.

Test-driven database development (TDDD) Recap

In simple words, TDDD is all about writing unit-test before the database object is even created. So, if we want to create a database object to satisfy some business requirement, it should be processed by creating a unit-test that ensures the object exists. Moreover, it has to be followed by another unit-test that will ensure the proper functioning of the database object (at the minimum) though that functioning check should only be limited to meet only the desired requirement. Read More

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

We discussed the basics of test-driven database development (TDDD) with examples and compared it with traditional database development in the first part of this article.

In the second part, we are going to move beyond basics to focus on a more realistic scenario of meeting report requirements by using TDDD.

A quick recap of TDDD at this point is handy in understanding how it can help us to achieve such goals.

Read More

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

Art of Isolating Dependencies and Data in Database Unit Testing

All the database developers more or less write database unit tests that not only help in detecting bugs early but also save a lot of time and efforts when the unexpected behavior of database objects becomes a production issue.

Nowadays, there are a number of database unit testing frameworks such as tSQLt along with third-party unit testing tools including dbForge Unit Test.

On the one hand, the benefit of using third-party testing tools is that the development team can instantly create and run unit tests with added features. Also, using a testing framework directly gives you more control over the unit tests. Therefore, you can add more functionality to the unit testing framework itself. However, in this case, your team must have time and a certain level of expertise to do this.

This article explores some standard practices that can help us to improve the way we write database unit tests.

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

Why Using Unit Tests is a Great Investment into High-Quality Architecture

I have decided to write this article in order to show that unit tests are not only a tool to grapple with regression in the code but is also a great investment into a high-quality architecture. In addition, a topic in the English .NET community motivated me to do this. The author of the article was Johnnie. He described his first and last day in the company involved in the software development for business in the financial sector. Johnnie was applying for the position – of a developer of unit tests. He was upset with the poor code quality, which he had to test. He compared the code with a junkyard stuffed with objects that clone each other in any unsuitable places. In addition, he could not find abstract data types in a repository: the code contained only binding of implementations that cross request each other.

Read More