6

What I know is:

  • A Functional test aims to test a single component (like a WebApp's Controller) from the point of view of the developer. => Did I achieve all the requirements to make it work well?
  • An Acceptance test aims to to test a group of components together and is focused on the Business point of view. => Does my program fulfill requirements provided by the Client/Business/Customer?

Today, I work on a personal project and I started following BDD/testing methods and thus created Acceptance tests and Functional tests.

I notice that a lot of requirement for functional tests are exactly the same that Acceptance tests need.

Suppose a webapp controller aiming to add a product to my e-commerce's basket.

One of concerned functional tests would be:

When I go to productList.html page and I call the addProductToBasket action, I expect my controller to retrieve the right quantity and the right product name, and expect my view to display it. (very generic)

Surely, Business would expect application to behave the same way a developer had written in some of its functional test, so in this case, an acceptance test would be:

Given Bob enters in the product list page, when he clicks on the button "addToBasket" near to the "Nike basket n°2" product, basket should display quantity '1' and "Nike basket n°2". (specification by example)

Both tests are very similar, aren't they?

So my question is: Do we risk to create a lot of duplication code and redundant tests while creating functional and acceptance tests in parallel?

What is a good practice? Making functional test carry about some pure technical things only, like exceptional/buggy behaviours, inconsistent variables scenarios etc... and let acceptance tests deal with the whole business scenarios side?

I would even say: Is functional testing really needed when we attach a huge importance to acceptance test?

Mik378
  • 3,838
  • 7
  • 33
  • 60

2 Answers2

6

yes, there can be duplication. Often with line of business type websites, you find the acceptance tests can actually substitute for developer oriented tests, because the depth of code needed to implement features is not too great. As a comparison, image recognition software may have huge depth, but at an acceptance level it might be simple as needs to recognize this as a circle, and this as a square. Developer wise, you need to test your image capture, light correction, object detection, object recognition, blah blah....

So if you have a shallow amount of code between acceptance and implementation, it quite often does feel redundant.

However, there are a few other differences in terms of process. You can have a suite of acceptance tests build up, and they don't all have to pass all the time, they can act as targets, so you go from 5% passed, to 10% to 50% etc, until you knock all the tests off. In some cases, ideally these tests can be put together semi independently of the developer. Developer oriented tests, the intention there is to have them passing all the time.

Keith Nicholas
  • 690
  • 1
  • 6
  • 12
  • Really like your answer :) – Mik378 Feb 21 '13 at 02:26
  • That means that acceptance testing fits well with TDD since "target focus" whereas functional tests don't. Is it a bad thing to drive my implementation from functional test although functional test are far more complete and deeper than acceptance test? – Mik378 Feb 21 '13 at 02:34
  • context plays a big part in this, you could just do acceptance testing and drive your code from that. You could just do functional testing and drive your code from that. Neither is 'bad' but just not always appropriate. In general, if you are new to it all, do both. This will let you learn to do both efficiently and find the right balance of testing. You may find your developer driven testing becomes more focused on smaller chunks – Keith Nicholas Feb 21 '13 at 02:54
  • ie, this tale of pottery is relevant http://pottery.about.com/od/apottersconceptualspace/a/apocrytale.htm the idea is, best way to learn something is do it lots, don't worry too much about getting things perfect from the start :) – Keith Nicholas Feb 21 '13 at 02:57
1

Yes, Tests should exist at multiple levels, in multiple forms and yes, you will see a lot of redundancy.

For example in a MVC you may have test in all three places that are checking on the value of an attribute. This can be seen as as a positive thing because then you can change any piece and know the effect of the change.

So yes, as you mention the different tests should test different things. Database tests can exercise CRUD operations and check the results, middleware can be tested similarly and can be used to actually drive the development (TDD).

Front-end tests can make sure that the user actually ends up seeing the intended results, regardless of the vagaries of output devices and versions.

Michael Durrant
  • 13,101
  • 5
  • 34
  • 60