What is the difference between integration tests and acceptance tests? application

Hi. I am busy working through this book: https://shankardevy.com/phoenix-inside-out-mpf/
It implements an online store by means of TDD in Phoenix. I am confused, however, as the author of this book only uses acceptance tests (via Hound) and unit tests. In the book, Programming Phoenix, the author used integration and unit tests only. Comparing the integration tests from Programming Phoenix with the acceptance tests from this book, it seems they basically test the same thing. What is the difference between them. How do you write integration and acceptance tests without repeating what is being tested?

Any help, advice and resources will be appreciated. I am somewhat new to the world of TDD and best practices regarding testing.

1 Like

Colloquially, (and probably in most applications) they’re often the same.

Technically, acceptance tests have to do with engineering specs - does the spec that you’re sending to your end user match the actual behavior of the system.

Integration tests are any collection of tests that cross coding boundaries. Acceptance tests are almost always a strict subset of Integration tests.

“If it hits the database it’s an integration test”. “If it goes over the network it’s an integration test”

Honestly, if you do it right elixir database tests are so fast that I typically lump them in with the unit tests (as a matter of code organization in directory structure, I label fast tests as ‘unit’ vs slow ‘integration’ tests). This is sloppy, but nobody bats an eye.

Happy to be corrected and learn if someone else has a different view of this!

2 Likes

Integration tests pertain to a single code base and check whether modules work when they are combined together. They are written by the same engineers that write the code base.

Acceptance tests are about the entire product and mimic the actions of an user (good or bad). They are written and run by another team, usually.