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 n2 product, basket  should display quantity '1' and Nike basket n2. (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?
Functional testing and Acceptance testing leading to redundant code
testing;tdd;bdd;acceptance testing;functional testing
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.