What is the difference between Integration Test & Acceptance Test

@AkiyamaSmart There is a subtle difference between how you are performing the test and why you are performing the test. To explain it better wrt registration example,

A) Why you are performing the test, can have couple of possible answer

1)  To test if the registration works (conducted by developer/tester) - Functional test
2) To sign off the feature (conducted by end user) - Acceptance Testing

B) How you are going to perform this test

1) As a standalone unit (Unit Testing)
2) Integrate it with existing modules (Say suppose you have a module responsible for notify clients, your registration module needs     to integrate itself with it)
3) System wide testing : End to end testing of system

and so on an so forth ....

@AkiyamaSmart I would not worry too much about the terminology - it will drive you mad! I used to get caught up into what type of tests I am writing, and realised I spent more time worrying about writing my test to fit within textbook definitions than developing the actual systems the tests were supposed to help build. Now I realise that the lines between each type of tests are blurred when doing real development unlike in contrived simplistic tutorials.

What I find more helpful to understand is the different approaches to testing that you can follow. By this I mean:

"Strategic" level: Test-First (TDD) or Test-Last (Regression Tests)

Most of the tutorials within the Laravel (indeed the PHP) community are about writing tests after writing the code. Whilst there is benefit to this when it comes to changing your code later (by way of writing a regression suite you can use for refactoring / future changes), you miss out on the main strength of writing tests, which is TDD. With TDD you write your tests first then write the code to make the tests pass. Benefits include:

• Discovering your emergent design as you write the tests. You start with a goal and not (normally) an implementation, then write the tests to design the way towards your goal and then write the code to pass the tests. The level of abstraction here means you do not get caught up in thinking about the implementation details.
• Removing yourself a level from the code to think about the system from a behavioural point of view.
• Slowing down the coding process, to help give yourself time to think and not just churn out rubbish code.
• Seemingly contradictory to the last point; speeding up the development process. With TDD you need to keep less of the system context in your head at once. This allows you to focus on the piece of code you are implementing, in the knowledge that the rest of the code that has come before it works as required, and the code you are writing now should not break it (and if it does, you have the tests in place to easily fix it!)
• Greater test coverage; you tend to think of the edge-cases a lot sooner and often write tests for the sad path, whereas writing test-last will tend to focus on the obvious, which is the happy path only.
• Refactoring is simple and true to the needs of the design. If you write your tests after the code, then what guarantees do you have that you have written the right test for your code? It doesn't take long to forget what the code you have written does! If your Test-Last test passes, but it is not testing everything, then you have some unaccounted for edge-cases (potential bugs). With TDD you will tend to test more of these edge-cases as you develop your design, therefore you have more coverage.

I'm sure if I had the time, I could give you another list of 4-5 big reasons why TDD is far superior to Test-Last.

"Tactical" level: Outside-In & Inside-Out

As opposed to thinking about integration tests, unit tests, functional tests, acceptance tests, end-to-end tests etc. try to think of the pattern of your test running through the different layers of the system (like layers of an onion).

You can start in the middle with a "unit" test and then jump out of the layers to write tests for code that hits more dependencies, or you can start on the outside to write a test that touches everything (aka integration test / acceptance test / end-to-end test - with 3 overlapping types, you can see why I don't bother naming them too much!) and drops you deeper into the system to write the more specific tests and implementation codes. You can then drop in and jump out to the levels you need to make the tests pass.

In all, think about the flow of the tests and what dependencies they hit, and it will all come together well and don't get hanged up about the names of the types of tests you are writing...

@ifpingram I agree with you, if you are a hobbyist or a freelancer, but if you are a professional developer then it helps if you have your terminologies straight as these are the jargons every one expect.

Just like a doctor, telling you, believe me i know what you have and what i am doing to treat you but i don't have a word for it. How are you gonna take him. Seriously, won't be the word you are looking for.

@premsaurav I don't think it matters in what capacity you are developing. I do this professionally and the more I do TDD it in my work capacity, the less I find myself explicitly naming the types of tests I am writing.

There may be many people / colleagues that you work with who are used to describing the types of tests, in order to tick boxes regards their development work, in which case I understand it is difficult to get them out of this mindset of having to name everything.

However, IMO, the only questions should be about the process and not the results, e.g. did you BDD / TDD the code? If not treat it as one big spike; scrap it and start again if you want to push it to production (unless of course you have the resources to assign a maintenance coder to the project from the beginning!).

Also your analogy about Doctors is not suitable; we're comparing apples and oranges; software development is not remotely like healthcare. Furthermore, my recent experiences with Doctors (here in UK) has led me to believe that the majority have a far less deep subject understanding than they would lead us to believe, indeed far less than I myself have about my sphere of computing. I have found they would rather leave something unidentified if they see something is wrong but cannot identify themselves. This approach is far worse than your analogy!

@ifpingram I do not intend to argue here and seriously wish there were more people like you who are more process oriented than result oriented. Globally we are moving towards it. But to fit into society, you must know the language they speak. If i talk Sanskrit and you German, we wont we able to communicate until we come to a common ground.

Anyway, i presumed, from his previous posts that he may be trying to learn about Software Testing. Why not learn it thoroughly. If you say so , it may be a waste of his time, you may be right, but i don't agree.

@premsaurav heh - sorry I didn't mean to come across as argumentative; I'm really enjoying the discussion - I guess we've hijacked this thread enough :)

I definitely think there is a good discussion here, as I don't think the software industry is on the right path entirely here, but that's for another thread.

To cut through all my waffle above, my point is that I completely understand @AkiyamaSmart 's frustration, as I've been there myself (I guess we all have), and to not let yourself get too worries about the distinctions at first, because with the more tests that you write, the types of tests you are writing will start to feel obvious and you can put a name to them (although by this point you'd hopefully be confident enough to not worry so much about pigeon-holing them).