30

Given I have written good unit tests for business rule units of a system. Is it still needed to write acceptance tests that target verifying those business rules implementation?

Improve this question
3
  • 5
    What's unclear in this question? Why people vote to close it?
    – dzieciou
    Jan 10, 2017 at 12:46
  • 3
    @dzieciou I suspect we have "closing mafia" of newer members, who recently got enough XP so they can close questions, so they do. You know who they are: same few. Hint: none of them answered the question.
    – Peter M. - stands for Monica
    Jan 10, 2017 at 14:40
  • 1
    Ask yourself this, if a System Tester or End User uncovers a fault that your testing did not what was the test they executed and should you also have executed it?
    – Paul
    Jan 11, 2017 at 15:12

9 Answers 9

Reset to default
37

Is it still needed to write acceptance tests that target verifying those business rules implementation?

Yes, it is absolutely necessary.

Your unit tests cover the business rules in isolation. Your acceptance tests verify that the application properly implements those business rules from a customer perspective.

There are many cases where the unit tests of the business rules pass, but problems with integration cause the acceptance tests for those rules to fail.

Update to answer OP's questions:

Unit Tests - test only the unit in isolation. They are not customer-focused.

Integration Tests - test that the units work together. They are not customer-focused.

Acceptance Tests - test that the customer's use cases are complete in a way that satisfies the customer's needs. They are customer-focused, and may be performed by the customer rather than the development team.

Improve this answer
13
  • 1
    They are not. Integration tests are not from a customer perspective.
    – Kate Paulk ♦
    Jan 10, 2017 at 13:14
  • 4
    You need unit, integration AND acceptance tests.
    – Kate Paulk ♦
    Jan 10, 2017 at 13:19
  • 2
    @MohammadaminKhayat this is not talking about using the same tests at different levels. It is about using appropriate tests for each level.
    – Kate Paulk ♦
    Jan 10, 2017 at 14:57
  • 4
    @MohammadaminKhayat: consider the possibility that the unit test for the business rule passes (because the rule is correct), but the acceptance test for the business rule fails because due to some misconfiguration or other horrible screw-up, the code doesn't always invoke the business rule when it should. Frankly, if you're only going to test once to avoid redundancy (which I don't advise, but seems to be your motivation), keep the acceptance test. Unit tests are extremely useful and make it easier to work, whereas acceptance tests determine whether you've created what the user wants.
    – Steve Jessop
    Jan 10, 2017 at 16:35
  • 3
    ... looked at another way, the unit test says, "we have a function/class/whatever that implements a particular behaviour that is required of the application", whereas an acceptance test says, as near as possible, "the application has the required behaviour". It's the difference between testing that you own a screwdriver, and testing that your furniture is screwed together ;-) That said, if your acceptance test does enough to prove that the correct business rule has been invoked, that might be good enough without having to re-test every conceivable edge case within the rule.
    – Steve Jessop
    Jan 10, 2017 at 16:45
5

Yes you should have scenarios which verify the unit tested business rules.

Some reasons:

  • good unit tests mock and stub the datastore. Acceptance tests make sure it is configured and works correctly.
  • unit tests usually test logic but don't allow for usability and accessibility
  • unit tests don't test whether the application works on the vast array of devices and browsers that are available today.
  • many of the problems that plague systems are due to software configuration management and require acceptance testable systems that reflect production configuration, frequently on a 'staging' server. Developer setups do not usually reflect the production configuration.
Improve this answer
2
  • I know the value of acceptance test, but in this case Do I need to have acceptance tests to verify the business rules which already verified by unit tests?
    – Polymorphic
    Jan 10, 2017 at 12:03
  • OK so no you don't, just whether those rules actually work within the context of the application itself. If login is required and you can't log in, the rules don't matter. However to test the rules in isolation unit tests are fine. Yes we get that. I think you're repeating your own answer ('no') at this point :)
    – Michael Durrant
    Jan 10, 2017 at 12:44
2

Good unit tests are not interchangeable with acceptance tests. They are different concepts and serve different purposes.

  • Unit tests, as its name suggests, they are aiming at testing individual units. Besides, how do you define "good" unit tests?
  • Acceptance tests are carried out as if you were a customer, you would expect all individual units of your code have been integrated together; if you do not execute acceptance tests, how would you detect communication issues between units?
Improve this answer
1
  • I am pointing to a specific part of the system: "Business rules" which means I have units that implement business rules. I am able to unit test these units with appropriate test cases and test data and make sure they pass tests when I change something in their scope. I am not telling that I won't write acceptance tests at all, but my question is: "Is it necessary to have scenarios which try to verify those unit-tested business rules?".
    – Polymorphic
    Jan 10, 2017 at 8:25
2

Yes, most of the time you do.

Personally I have implemented some new features TDD, with 100% unit-test coverage on my classes, but I forgot to update the implementation code that was used during the bootstrapping. I needed to add a couple of integration-tests to cover this situation.

Eventually you also want to check the full end-2-end stack with a couple of tests. If not only to make sure that if something breaks you can add these types of tests in a later stage. For example when something is hard to test at unit level. If you do not create end-2-end tests from the beginning you might realize to late that you build your UI untestable or just very hard to test.

You do need to find a good balance between different test types, read about the test pyramid. Still focussing mainly on unit-tests is good, but just not good enough.

Other reads:

Improve this answer
1
2

As others have mentioned, unit tests cover functionality in isolation. There's a great little illustration of why that's not enough that's gone around recently. It can be seen here: https://www.youtube.com/watch?v=0GypdsJulKE

Now, that's funny and it makes for a great joke, but there's value in remembering that your code doesn't live in a vacuum. Software is made up of components that must work together. Unit testing is about isolating a single component and making sure that it behaves the way it should. Integration and acceptance testing is about making sure that components work together to meet the acceptance criteria and, by extension, the business need.

Improve this answer
1
  • I would actually consider the tests pictured in that youtube video to be unit and integration tests; an acceptance test in the same analogy would be a second individual attempting to enter the room - so even if the lock was appropriate for the door (a successful integration test), the second person might enter through the window and produce a failure on the acceptance test.
    – Dan Henderson
    Jan 12, 2017 at 14:22
2

Unit tests and integration tests are designed to facilitate the development of the product. Oversimplifying in this area can lead to difficulty in regression testing and failure/fault isolation, regardless of where a problem is first discovered.

Acceptance testing is usually done in a manner agreed to by the end user or customer and is solely focused on the functional and performance results that they expect to see. Acceptance tests are not intrinsically expected to be used in failure isolation, even when the failure is discovered as part of the acceptance test. They may be used to gather insight to what may have caused the failure, but should not be so complicated that they are also expected to be used to determine a root cause in the software.

Note that a failure in an acceptance test may not be due to a fault in the software. It may be due to an error in understanding the requirements and implementing incorrectly. Unit tests and integration tests will not necessarily uncover this type of failure.

Improve this answer
1

Good unit tests are your first line of defense. But as any strategist can tell you, one line of defense is never enough. You expect that some of your unit test will fail to catch some issues (or it is hard to write a unit test for, or test coder did not thought about some combination, or error happened in unexpected way - there are many reasons) so you have higher-level tests.

It is called "defense in depth" strategy. Read up on strategy. Sun-Tzu is a good start for more than 2 millennia :-)

Improve this answer
1

Unit tests and acceptance tests need fundamentally different approaches

  1. Unit tests check that your code does was you think it does, but not whether that is the correct thing to do. A good unit test checks that you have implemented the low level structure of your functions (or units) without any straight-forward errors.

  2. Acceptance tests check that the combination of your little units of code is doing something that is overall sensible and correct for your use case. You've verified that your code does what you expect it to with unit tests, but acceptance tests help to check that your mental model is correct, and that the code you've written actually solves the problem you set out to solve.

Improve this answer
1

Would you buy an keyboard whose every key has been tested but somehow does not work with your computer system?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.