Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

At our company we typically make sure that we write an end-to-end test for our websites/web apps. That means we access a URL, fill in a form, submit the form to another URL and check the results of the page. We do this to test form validation, test that the HTML templates have the correct context variables, etc.

We also use it to indirectly test the underlying logic.

I was told by a co-worker that the reason for this is that we can rip out and change the underlying implementation at any point as long as the end-to-end tests pass.

I'm wondering if this sort of decoupling makes sense or if it's just a way to avoid writing tests for smaller units of code?

share|improve this question
was told by a co-worker that the reason for this is that we can rip out and change the underlying implementation at any point as long as the end-to-end tests pass. -- That's also true of unit tests. It sounds to me like the end-to-end tests are being used as an excuse for not writing unit tests. –  Robert Harvey May 21 '13 at 18:03
That is not true of unit tests. Changing/removing/creating methods or classes require updating all unit tests for those methods or classes. Not so in end to end tests unless the end user functionality is changing. As long as it's a system level refactor (no modification of end user functionality) no changes are required to the end-to-end tests. –  dietbuddha May 22 '13 at 7:11
@dietbuddha, I think the general concept is true of unit tests, but at a smaller (unit) scope. –  Sam Oct 11 '13 at 9:07

4 Answers 4

up vote 15 down vote accepted

End-to-end tests are also necessary. How else can you know you hooked up all the units together correctly? On very simple code, it is possible to test all the paths through the code with only end-to-end tests, but as you get more layers, it becomes prohibitively more costly to do so.

For example, say you have three layers, each with five possible paths. To test all the paths through the entire application would require 53 end-to-end tests, but you can test all the paths through each unit with only 5·3 unit tests. If you only do end-to-end testing, a lot of paths end up getting neglected, mostly in error handling and boundary conditions.

share|improve this answer
That's a good answer. I see the value of both but seeing the number of possibilities for fully testing all paths with end to end tests is helpful for explaining why unit testing needs to be done more than it is –  omouse May 21 '13 at 18:00
I see unit tests as being valuable mostly because they localize problems quickly. End-to-end are valuable because they give you confidence that everything works together. –  Jason Swett May 21 '13 at 19:14

Yes, end-to-end tests (or integration tests) make a lot of sense, but so do unit tests, too. Ideally, you have both of them, since both typically catch different kind of bugs. Thus, having end-to-end tests should never be an excuse for not having unit tests.

share|improve this answer

Actually end-to-end tests, or integration tests are more important than unit tests since they assure that you have a fully working system. Unit tests don't cover the integration part of a system, which is a complicated task especially in large projects.

However as it has been said, you should do unit testing also, since it is more complicated to catch the edge cases in integration testing.

share|improve this answer

It verifies system behavior, whereas unit tests verify unit behavior. The benefits and costs for each are different. You could do one or the other or both.

At my work we do Acceptance Test Driven Development without unit tests which sounds similar to what you've described. We started out doing both and over time, eventually eliminated unit testing do to the cost exceeding the benefits for us.

That being said I think the cost/benefit for your problem domain and environment should drive the decisions to engage in any development practice, different automated testing practices included. Rather than faith, I prefer all practices to have empirical evidence within the context of there use to back them up.

share|improve this answer
What I'm worried about is that we'll be coding towards acceptance tests which leads to large classes or methods instead of smaller units. –  omouse May 22 '13 at 16:35
@omouse: Just because you aren't writing unit tests is no reason not to write good code. However, if you have programmers who are inexperienced or just have bad habits then the benefits may outweigh the costs. In either case you should do the analysis and reduce it to a simple equation. For Any Practice: Practice iff Benefit > Cost –  dietbuddha Jun 15 '13 at 3:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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