Scribd
Upload
34 views

Test Driven Development

Test-driven development (TDD) is an approach where tests are written before production code to specify requirements and drive the development process. TDD is commonly used with object-oriented languages like Java and C#, but the same principles could be applied to database development by writing tests before making schema changes. While tools to support test-driven database development are emerging, it is not yet widely adopted due challenges including lack of tooling and cultural preferences within the data community for model-driven over test-driven approaches. As tools and acceptance of evolutionary development models grow over time, test-driven database development may become more common.

Uploaded by

testm tester
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
34 views

Test Driven Development

Test-driven development (TDD) is an approach where tests are written before production code to specify requirements and drive the development process. TDD is commonly used with object-oriented languages like Java and C#, but the same principles could be applied to database development by writing tests before making schema changes. While tools to support test-driven database development are emerging, it is not yet widely adopted due challenges including lack of tooling and cultural preferences within the data community for model-driven over test-driven approaches. As tools and acceptance of evolutionary development models grow over time, test-driven database development may become more common.

Uploaded by

testm tester
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

TEST DRIVEN DEVELOPMENT

Test-driven development (TDD) (), is an evolutionary approach to


development which combines test-first development where you write a test
before you write just enough production code to fulfill that test What is the
primary goal of TDD? One view is the goal of TDD is specification and not
validation . In other words, it’s one way to think through your requirements
or design before your write your functional code (implying that TDD is both
an important agile requirment and agile design technique). Another view is
that TDD is a programming technique. As Ron Jeffries likes to say, the goal
of TDD is to write clean code that works.
At the time of this writing an important question being asked within the agile
community is “can TDD work for data-oriented development?” it is
important to note that none of the steps specify object programming
languages, such as Java or C#, even though those are the environments TDD
is typically used in. Why couldn't you write a test before making a change to
your database schema? Why couldn't you make the change, run the tests, and
refactor your schema as required? It seems to me that you only need to
choose to work this way.
My guess is that in the near term database TDD, or perhaps Test Driven
Database Design (TDDD), won't work as smoothly as application TDD. The
first challenge is tool support. Although unit-testing tools, such as DBUnit,
are now available they are still an emerging technology at the time of this
writing. Some DBAs are improving the quality of the testing they doing, but I
haven’t yet seen anyone take a TDD approach to database development. One
challenge is that unit testing tools are still not well accepted within the data
community, although that is changing, so my expectation is that over the next
few years database TDD will grow. Second, the concept of evolutionary
development is new to many data professionals and as a result the motivation
to take a TDD approach has yet to take hold. This issue affects the nature of
the tools available to data professionals – because a serial mindset still
dominates within the traditional data community most tools do not support
evolutionary development. My hope is that tool vendors will catch on to this
shift in paradigm, but my expectation is that we'll need to develop open
source tools instead. Third, my experience is that most people who do data-
oriented work seem to prefer a model-driven, and not a test-driven approach.
One cause of this is likely because a test-driven approach hasn't been widely
considered until now, another reason might be that many data professionals
are likely visual thinkers and therefore prefer a modeling-driven approach.

You might also like