What is the difference between integration testing and functional testing? [closed]

Question

Integration testing is when you test more than one component and how they function together. For instance, how another system interacts with your system, or the database interacts with your data abstraction layer. Usually, this requires a fully installed system, although in its purest forms it does not.

Functional testing is when you test the system against the functional requirements of the product. Product/Project management usually writes these up and QA formalizes the process of what a user should see and experience, and what the end result of those processes should be. Depending on the product, this can be automated or not.

Functional Testing:

Yes, we are testing the product or software as a whole functionally whether it is functionally working properly or not (testing buttons, links etc.)

For example: Login page.

you provide the username and password, you test whether it is taking you to home page or not.

Integration Testing:

Yes, you test the integrated software only but you test where the data flow is happening and is there any changes happening in the database.

For example: Sending e-mail

You send one mail to someone, there is a data flow and also change in database (the sent table increases value by 1)

---

Remember - clicking links and images is not integration testing. Hope you understood why, because there is no change in database by just clicking on a link.

Hope this helped you.

Functional Testing: It is a process of testing where each and every component of the module is tested. Eg: If a web page contains text field, radio botton, Buttons and Drop down etc components needed to be checked.

Integration Testing: Process where the dataflow between 2 modules are checked.

This is an important distinction, but unfortunately you will never find agreement. The problem is that most developers define these from their own point of view. It's very similar to the debate over Pluto. (If it were closer to the Sun, would it be a planet?)

Unit testing is easy to define. It tests the CUT (Code Under Test) and nothing else. (Well, as little else as possible.) That means mocks, fakes, and fixtures.

At the other end of the spectrum there is what many people call system integration testing. That's testing as much as possible, but still looking for bugs in your own CUT.

But what about the vast expanse between?

• For example, what if you test just a little bit more than the CUT? What if you include a Fibonacci function, instead of using a fixture which you had injected? I would call that functional testing, but the world disagrees with me.
• What if you include time() or rand()? Or what if you call http://google.com? I would call that system testing, but again, I am alone.

Why does this matter? Because system-tests are unreliable. They are necessary, but they will sometimes fail for reasons beyond your control. On the other hand, functional tests should always pass, not fail randomly; if they are fast, they might as well be used from the start in order to use Test-Driven Development without writing too many tests for your internal implementation. In other words, I think that unit-tests can be more trouble than they are worth, and I have good company.

I put tests on 3 axes, with all their zeroes at unit-testing:

1. Functional-testing: using real code deeper and deeper down your call-stack.
2. Integration-testing: higher and higher up your call-stack; in other words, testing your CUT by running the code which would use it.
3. System-testing: more and more unrepeatable operations (O/S scheduler, clock, network, etc.)

A test can easily be all 3, to varying degrees.