kind of tests
- View SourceHi guys,
I would like to draw a picture of the different kind of tests but I am
a bit confused with definitions.
According to Steve and Nat (www.mockobjects.com/book)
does the whole system work?
does our code work against code we can't change?
do our objects do the right thing, are they
convenient to work with?
Where are functional tests in those leve of testing?
Adam Sroka wrote something that seems to be different:
"Traditionally, "functional test" is a synonym for "system test." It
refers to testing the entire system in the context of that system's
functional requirements. A "unit test" tests a unit in isolation. An
"integration test" tests more than one unit in combination, but not
necessarily the entire system. A system/functional test is a special
case of integration testing where the combination of units being
integrated encompasses at least one route through the entire system.
None of these definitions considers who owns the components being
According to Adam, an integration test does not mean we can't change
the code, it is just a system test.
Eventually the picture I've got in my mind is:
- Unit tests :
Isolated, atomic, innocous: exercised with xUnit
- Integration tests
Isolated tests that might change the state of the
system, i.e: saving into database, writing file...
An integration test does not represent a functional
requirement as is.
Can be written for xUnit. They check the integration
of our coude with a third party tool or with the different layers of
our own code,
i.e: the business logic layer requires the data access layer
- Functional tests (also known as System tests):
A test that excersises part of the system as a whole,
some functional requirement. It might change the status of the system.
Product Owner tests:
- Acceptance tests:
Functional tests which input and output can be
validated by a non-technical person, the product owner.
Would you agree with this?
Why do I need to be that precise with these definitions?
I am writing a book on TDD in Spanish and would like to be precise. To
me, that fact that I am writing a test and I can't tell what kind
of test it is, is a code smell, either in the test or in the sut. So I
consider that making clear the type of tests is important.
Hopefully the book will be ready before the end of 2009
- View SourceOn Tue, Jul 28, 2009 at 2:03 AM, Nat Pryce<nat.pryce@...> wrote:
>Perhaps, but I still haven't quite grokked the distinction you are
> 2009/7/28 Adam Sroka <adam.sroka@...>:
>> On Mon, Jul 27, 2009 at 5:21 PM, Nat Pryce<nat.pryce@...> wrote:
>>> 2009/7/22 Adam Sroka <adam.sroka@...>:
>>>> 2) The notion that developers care more about how we test than for
>>>> what we test. I don't think that this is correct. I, for one, care
>>>> more about what is being tested than how.
>>> I didn't say that or mean to imply that. It would be ridiculous if
>>> developers cared more about how their tests worked than what they were
>>> actually testing!
>> I won't presume to know what you meant. But, you *did* say that
>> customers care about what was tested and developers care about how it
>> was tested and the two are orthogonal (Which implies mutual
>> exclusivity... otherwise it couldn't be "orthogonal.")
> We're rapidly spiraling into pedantry, but that implication does not hold.
making. So, perhaps it's more about thickness than pedantry ;-)
> Given that customers care about what is tested and do not care aboutOkay, but that doesn't sound "orthogonal" to me. There is a shared
> how it is tested, the fact that developers care about how it is tested
> does not imply that developers do not care care about what it is
goal (Specifying "customer" level behavior) and a separate goal that
the customer generally doesn't concern herself with (Verifying
technical details.) But, we certainly "care" about both, and I'm not
convinced that verifying technical details is entirely independent -
there should always be a business purpose underlying every technical
> The aspects of "what" and "how" are orthogonal. I can write a testI see "what" as "what the customer asked for" and "how" as "the
> that expresses system behaviour (the what) and implement the test to
> drive the system in different ways (the how).
> But I, as a developer, *care* about both concerns, even though I can
> consider them independently.
simplest thing that could possibly work." The two aren't independent.
The former drives the latter.