Unit Tests vs. Acceptance Tests RRS feed

  • General discussion

  • Are you for one or the other? Or both?

    My understanding is unit tests:

    • validate the system from the developer's point of view
    • help developers practice TDD
    • keep code modular
    • assist in detecting errors at low levels of granularity

    Acceptance tests:

    • validate the system from the business and QC / QA points of view
    • tend to be high level as they're often written by people not familiar with the inner workings of the code

    I feel both are necessary. However, for minimization of redundant work, is it a good idea to try to incorporate unit tests into acceptance tests? In other words, have the latter call the former. Does going in the opposite direction make any sense?

    What are your thoughts in general on unit tests vs. acceptance tests, and how to manage them in relation to each other?

    Tuesday, November 9, 2010 10:01 PM

All replies

  • Hello there,

    some links are given below

    TDD with Acceptance Tests and Unit Tests

    Acceptance Testing vs. Unit Testing: A Developer’s Perspective

    Xp Vs Standard Definition Of Unit Test

    Acceptance Testing vs. Unit Testing

    Overview on TDD (Test Driven Development) & ATDD (Acceptance Test Driven Development)

    Hope this helps


    Phijo Mathew Philip

    Wednesday, November 10, 2010 6:14 AM
  • Hello there,

    A link is given below

    The New Methodology

    Hope this helps.


    Phijo Mathew Philip.

    Wednesday, November 10, 2010 6:34 AM
  • Hello there,


    Hope this helps


    Phijo Mathew Philip.

    Wednesday, November 10, 2010 7:13 AM
  • Unit testing used to be a term describing a developer testing each module or screen  - each unit.

    Then automated testing came along and some people call that unit testing. 

    What developer testing does is prove the thing works like the developer thinks it ought to work and does all the things he's thought of.

    User Acceptance Testing proves that the system does what the user expects and doesn't break when he does something the developer didn't think of.

    Both are vital.

    Whether automating testing actually saves time and is really better than test as you go is arguable IMO.  I've seen systems pass all unit tests then fail to work in ways that would have been obvious to a human tester.

    Personally I would recommend peer testing prior to showing anything to users.  It's all too easy for a developer to focus on details of implementation and not see the bigger picture.

    Wednesday, November 10, 2010 8:34 AM
  • Hi.  I perfectly agree with Andy’s opinion.

    I just would like to add that sometimes it’s very costly (time and effort) to manually test all the systems functionalities.

    So, IMO I would choose a mix: Human testing for the project changes (new functionalities and fixes) + Automated testing for the remaining functionalities. I mean, to automate just the tests related to functionalities not directly affected by the changes, in order to make sure that these changes have not affected what was working before (aka Regression Testing).

    Best Regards,


    Wednesday, November 10, 2010 4:37 PM
  • Sorry.  I should have clarified.  I don't mean user acceptance testing.

    I mean acceptance tests from the point of view of Acceptance Test-Driven Development.  The doctrine of which is that acceptance tests are written and agreed upon by the entire team before development begins.  Developers then code with the awareness that their end goal is to make all acceptance tests pass (i.e., to meet all previously defined requirements).  Acceptance tests are automated via a framework like FitNesse.  This is very different from what you guys have in mind.

    Wednesday, November 10, 2010 6:01 PM
  • I think whoever came up with your terminology ought to pay a bit more attention to what the rest of the world already calls things, mate

    Plus I don't really see there's necessarilly any difference. 

    I'm a developer and I'm using automated unit testing with Nunit.  Why would my aim NOT be to make my code pass all defined requirements?

    Thursday, November 11, 2010 9:39 AM
  • I just would like to add that sometimes it’s very costly (time and effort) to manually test all the systems functionalities.


    On the other hand, there's also a significant cost in implementing automated unit testing.  This is especially true if you try and add it to a mature system since it often inveolves extensive refactoring of code which itself risks introducing bugs.

    Thursday, November 11, 2010 9:44 AM
  • Andy, if you've never heard of ATDD, and don't know the difference between unit tests and ATDD acceptance tests, both of which are automated, there's no need for you to continue paying attention to this thread.
    Thursday, November 11, 2010 6:09 PM
  • I had similiar thoughts about redundancy when I started using ATDD during a project.  Our usual TDD approach seemed to have become devalued as I felt there was some duplication.


    After thinking about this I came to the conclusion that the issue was the unit tests were confusing verification and specification.  I found that we lowered our unit testing effort by focusing these on specifying the behaviour of the software (specification).  This left the acceptance tests to verify the system does what the customer expected (verification).


    Previously we had been doing both specification and verification in our unit tests.  The introduction of ATDD made this redundant.


    One nice by-product of this is that I now automate the documentation of my projects by extracting all the unit test names into a document.  This has proved useful to non-functional testers.


    Hope this helps

    Pl mark as answer or helpful if you found this useful
    Thursday, November 11, 2010 9:13 PM
  • Thanks, G.  So in a nutshell your ATDD acceptance tests and unit tests are totally independent and separate layers of testing?

    I agree that unit tests in TDD are low level specification, but this is before the tests pass and "settle down" (i.e., are refactored).  Afterward they are both specification and verification at the low level.  Just as acceptance tests are both at the high level.

    Thursday, November 11, 2010 10:19 PM
  • Yes.  We found the acceptance tests useful but couldn't understand why doing something useful slowed us down.

    After identifying the redundancy it was a case making them complement one another.

    Pl mark as answer or helpful if you found this useful
    Thursday, November 11, 2010 10:29 PM