Loading ...
Sorry, an error occurred while loading the content.

kind of tests

Expand Messages
  • Carlos Ble
    Hi 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
    Message 1 of 74 , Jul 7, 2009
    View Source
    • 0 Attachment
      Hi 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)
              Acceptance
                       does the whole system work?
              Integration
                      does our code work against code we can't change?
              Unit
                      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
      tested."

      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:
       Developer tests:
             - 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

      Thanks :-)
    • Adam Sroka
      ... Perhaps, but I still haven t quite grokked the distinction you are making. So, perhaps it s more about thickness than pedantry ;-) ... Okay, but that
      Message 74 of 74 , Jul 28, 2009
      View Source
      • 0 Attachment
        On Tue, Jul 28, 2009 at 2:03 AM, Nat Pryce<nat.pryce@...> wrote:
        >
        >
        > 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.
        >

        Perhaps, but I still haven't quite grokked the distinction you are
        making. So, perhaps it's more about thickness than pedantry ;-)

        > Given that customers care about what is tested and do not care about
        > 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
        > tested.
        >

        Okay, but that doesn't sound "orthogonal" to me. There is a shared
        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
        decision.

        > The aspects of "what" and "how" are orthogonal. I can write a test
        > 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.
        >

        I see "what" as "what the customer asked for" and "how" as "the
        simplest thing that could possibly work." The two aren't independent.
        The former drives the latter.
      Your message has been successfully submitted and would be delivered to recipients shortly.