David Karr davidmichaelkarr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [seajug]
2014-05-10 16:46:32 UTC
I would assume that anyone reading this has a pretty clear idea of what
"test-driven development" (TDD) means, but perhaps there are subtle
variations between organizations.
The basic idea is pretty clear, even if there are numerous ways to say it.
You write and run test assertions before you write the code to fulfill
those assertions. You can argue about the wording (please don't) but
that's the basic idea.
This can be applied to any level of test (unit, integration, acceptance,
system, et cetera), but it's typically associated with unit tests.
One thing that might happen in organizations is that they assume that TDD
refers to the entire process of writing and running unit tests. If an
organization strictly follows TDD, according to the common definition, then
that's effectively what it is, the entire process of writing and running
unit tests, because you never do it in a different way.
However, it's also entirely possible that unit tests are written for
existing code, instead of using a TDD process (again, according to the
"standard" definition). This can happen for various reasons, but it does
happen. In fact, in many organizations that do write unit tests, this is
how almost all unit tests are written.
It seems possible to me (because I'm seeing it happen) that some
organizations will espouse a practice they call "test-driven development",
which simply means to them that developers are writing unit tests, without
any understanding of how that happens.
I can understand why this would happen. The phrase "test-driven
development" is nice and snappy, and there isn't really a nice sounding
phrase for the overall practice of writing and running unit tests, even if
that's what management wants to ensure is happening.
What is your experience in the organizations you've worked for? How common
is it to have developers writing unit tests for existing code, but having
the organization refer to it as "test-driven development"?
Personally, I've concluded that if I work for a large company and they
decide to call a luxury yacht a breadbox, I will happily ask them how large
an engine they want for their breadbox. However, when I talk to the boat
dealer, I obviously have to use the terms that are standard in the
industry. This is just how it is. I've tried to contest what I see as a
small misconception, but I've been told to "get off my high horse", so I
guess I have to adapt.
"test-driven development" (TDD) means, but perhaps there are subtle
variations between organizations.
The basic idea is pretty clear, even if there are numerous ways to say it.
You write and run test assertions before you write the code to fulfill
those assertions. You can argue about the wording (please don't) but
that's the basic idea.
This can be applied to any level of test (unit, integration, acceptance,
system, et cetera), but it's typically associated with unit tests.
One thing that might happen in organizations is that they assume that TDD
refers to the entire process of writing and running unit tests. If an
organization strictly follows TDD, according to the common definition, then
that's effectively what it is, the entire process of writing and running
unit tests, because you never do it in a different way.
However, it's also entirely possible that unit tests are written for
existing code, instead of using a TDD process (again, according to the
"standard" definition). This can happen for various reasons, but it does
happen. In fact, in many organizations that do write unit tests, this is
how almost all unit tests are written.
It seems possible to me (because I'm seeing it happen) that some
organizations will espouse a practice they call "test-driven development",
which simply means to them that developers are writing unit tests, without
any understanding of how that happens.
I can understand why this would happen. The phrase "test-driven
development" is nice and snappy, and there isn't really a nice sounding
phrase for the overall practice of writing and running unit tests, even if
that's what management wants to ensure is happening.
What is your experience in the organizations you've worked for? How common
is it to have developers writing unit tests for existing code, but having
the organization refer to it as "test-driven development"?
Personally, I've concluded that if I work for a large company and they
decide to call a luxury yacht a breadbox, I will happily ask them how large
an engine they want for their breadbox. However, when I talk to the boat
dealer, I obviously have to use the terms that are standard in the
industry. This is just how it is. I've tried to contest what I see as a
small misconception, but I've been told to "get off my high horse", so I
guess I have to adapt.