Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

renyan's avatar

Codeception, PHPSpec, Acceptance | Functional | Integration | Unit testing

Hello everyone,

Could someone help me to understand how all of these are used in a real project.

Take, for example the project that's being developed in Larabook series.

Jeffrey only used functional and integration tests.

Questions:

  1. When would Unit tests come in use?
  2. What's the practical difference between acceptance and functional tests? I understand that the former are virtual and no browser is used, so I guess you can't test javascript (?). (Functional for features without JS and Acceptance when tests are dependant on JS?)
  3. Any additional tips if I am understanding something incorrectly?

Please provide examples in relation to larabook series if you may.

Thanks in advance, R.

0 likes
14 replies
bacondrinker's avatar

I really would like @JeffreyWay to do a series breaking down the different kinds of tests, what they are, where they are used and an example of each of them.

I think there are many people who are overwhelmed by testing and what is out there, and I think a break down by Jeffrey might be able to help a whole bunch.

12 likes
austenc's avatar

I am currently using functional and acceptance testing via codeception in my app. Here's how I think about tests:

  • Acceptance tests are front-end only and you are testing whether you see the correct UI elements. This type of test never explicitly checks the database with a direct call. Think of it as only testing what an end-user would be able to see by clicking around in a browser.

  • Functional tests are similar to acceptance tests but they do check the database explicitly, something like $I->seeInDatabase() or $I->seeRecord(). Functional tests generally use a DOM parser instead of a browser (or phantomJS) like acceptance tests do -- this is why JS is best left to acceptance tests.

  • Unit tests are for testing a single responsibility / piece of logic. Usually unit tests describe your model or repository and ensure that each small piece (unit) works correctly. I don't have much experience unit testing with codeception so maybe someone else can elaborate further.

10 likes
janderson's avatar

I largely agree with austenc, but I think it bears mentioning that JS is often used on the server-side now, (or as the full-stack) and might need unit and functional tests, in that regard.

1 like
Alias's avatar

To be honest testing is still something that I don't do, and I know I should. What I think would be best if the series was much like the "Laravel for noobs" one, going from the absolute basics, working up to making it harder.

ccasselman's avatar

I see the "Larvel for Noobs" to be more on the lines of the "Laravel Way" or "Laravel Best Practices".

renyan's avatar

I see.. I will be waiting as my project is currently stopped due to lack of testing experience.

bart's avatar

I currently have the exact same question! In my opinion acceptance, functional and unit tests are exactly what @austenc wrote. But what are integration tests in that scenario? Any idea??

HRcc's avatar

@bart Imagine that you have unit tests for your code which are testing classes/modules/... (preferably) in isolation and then you can consider integration tests which will combine multiple modules/parts/units of your application to verify, if they interact in the way they should. For example you can test if an email (after completing registration/closing account/ ...) is sent.

bart's avatar

Hey @HRcc, thanks for your response! But isn't that nearly the same as a functional test? In my opinion all these different testing types can be described by mocking things, their environment, code related or browser related. Maybe we can find an example together, where we can describe all 4 testing types with? For me there really is a difference between acceptance, functional and unit testing. But I can't get the difference between "integration test" and functional test. Maybe functional tests can use a browser, where integration tests just using a plain mocked phpunit test but with more than just one private method - maybe one public method which is using multiple privates. What do you think?

ozanhazer's avatar

@bart that's what I saw in most of the discussions about integration and functional tests... Most of the time I read people describing them with different words but testing the same thing :) The difference is probably about the methodology and not about what you test...

In fact the definition of the tests and what the test suites does are not matching completely. There's no strict definitions of them and people are just defining their own strategies by looking at the nature of their project...

For example in my projects I do two types of tests, unit tests and selenium tests. I don't want to call selenium tests as a user acceptance tests beacuse it's smt. in between user acceptance, user interface and functional/integration tests:

  • User acceptance tests are not about testing the user interface, it's more about testing the user stories. (Google given-when-then stories). It's to test if the software is doing what it's designed to do... Unlike the functional and unit tests it has nothing to do with the technical details of the code and software design...

  • User interface tests are to test if there's smt. wrong with the user interface and selenium is used for that too that's why it's usually referred as a UA test too. The problem with that is, they're very very fragile...

  • Functional/integration tests are as defined above... With codeception you can test with browser and also check the database if the data entered in the browser is actually written in the database. Two birds with one stone, might sound good at the beginning but things can get messy easily.

  • Unit tests will make your code better designed, others will make you catch those nasty bugs... The primary benefit you'll get from the unit tests is the increase in the code quality because to write testable code the developer is forced to design code in smaller units.

As I said, everyone has their own way of organizing their tests...

Obviously, testing increases the initial cost but pays back in time.

So, if you're working on a long term project, yeah test everyting, it'll pay back... Otherwise you should find a good balance between what to test or not and how to test... Just keep in mind that unit tests are the cheapest, UI tests are the most expensive. (See test pyramid)

3 likes
bart's avatar

Hey @ozanhazer,

thanks for your time and the good description. That is what I thought about, too. I mean terminology doesn't really matter. The point is THAT you do testing.

In my opinion everything can be covered with codeception (unit, functional, acceptance). Developing a new feature and being sure, that everything works like before - or better as designed saves a lot of time and leads to a good quality of code.

Would you agree?

codenihal's avatar

Testing, Testing, Testing, Testing, TESTING, TESTING.

@JeffreyWay , Hopin for a new series where you Mock that Thang, and do odd things with Justin Bieber and (Ducks?????) what not..

Just Love Laracasts and Jeff

1 like

Please or to participate in this conversation.