Tag: tdd

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

Haroon Ashraf
Jump to Start Test-Driven Database Development (TDDD) – Part 3
4.3 (86.67%) 3 votes

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

Haroon Ashraf
Jump to Start Test-Driven Database Development (TDDD) – Part 2
Rate this post

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

Haroon Ashraf
Jump to Start Test-Driven Database Development (TDDD) – Part 1
Rate this post

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

Aleksandr Goida
Replacement of Algorithm Testing with Testing of Effects Being Inserted
Rate this post

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

Aleksandr Goida
Rules for Implementing TDD in Old Project
Rate this post

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