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:19 PM

All replies

  • To clarify, 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.

    Wednesday, November 10, 2010 6:02 PM
  • Hi Cal,

    You use Acceptance tests to test whether your system is able to perform the highest level of functionality. You provide some parameters, call a method and check the result. The implementation of the AT is done using unit tests.

    Now, the key point here is that once the AT are written (against high level interface), you start coding the implementation. Note that AT can be automated using Fitnesse, but I prefer waitin and MSpec (for library specs).

    Kind regards,
    Tom de Koning

    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Wednesday, November 10, 2010 8:33 PM
  • So you advocate calling unit tests from acceptance tests?  May I ask what is your preferred method for linking up FitNesse and Visual Studio unit tests?
    Thursday, November 11, 2010 6:12 PM
  • Hello,

    Unit tests would focus solely on the logic of the customization code itself.  That would be done by factoring the code to be tested into separate classes that could be instantiated either by the out View Object classes or by a test driver.  Unit tests should be fast and extremely incremental.  The point is to be able to run them in-line with code development.

    In addition, I am change the type of this post to 'General Discussion' which will draw people' attention who are interested in this issue.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help
    Friday, November 12, 2010 4:55 AM
  • So you're not a fan of attempting to call one type of test from the other.
    Friday, November 12, 2010 4:51 PM
  • I struggled with this question myself. One helpful essay I read was this: http://blog.objectmentor.com/articles/2007/10/17/tdd-with-acceptance-tests-and-unit-tests.

    Essentially Uncle Bob suggests that having the same code covered by both unit tests and acceptance tests is a good thing since it means that, when both types of test are passing, you can be assured that not only is the software working as you intended it, but that it is working as the business intended it as well.

    I agree mostly. However I would suggest that a little code re-use wouldn't be such a bad thing. Take the example of a submission of a web form where the user has failed to input one of many required field. The acceptance test criteria would be something like "If the user enters invalid details then show them the error, otherwise take them to the next page". Now imagine this is a big form with a lot of required fields and hundreds of possible data input scenarios, some of which are valid, and some of which aren't. In practice, you're not going to get business people writing acceptance tests which go in to that level of detail. They will expect the programmer to know what an invalid form looks like. The business people will only care about the two possible outcomes (error and success), so that's all they'll write user stories for.

    Being the developer that implements this acceptance test, you will need to input the various inputs for invalid forms. Following TDD you would have written these lower level tests anyway later on as unit tests, so why not re-use the same test code in both? This is where using the same framework for running unit tests and acceptance tests really becomes useful.

    Hope this helps.

    Saturday, November 13, 2010 9:35 PM