Hi, the good side of codeception is that it's very flexible and you can do whatever you want of kind of tests. The 3 predefined tests suites (unit, functional and acceptance) are only examples. It's up to you and how you're organization / project team is working to define what you want to do with this tests suites (and create more if you need).
To help you, let me share the configuration I'm using with most of my clients:
Unit Test : as defined in the book "Working effectively with legacy code" this tests are low level tests, and must be small, fast and shouldn't depend on the infrastructure (no database, no network, and no file system interaction, you can use
vfsStream), this are phpUnit tests (and codeception is based on phpUnit, then it's the same)
Acceptance Test : for me this are the higher possible level of tests, I'm using BDD tests. This tests should not be written with technology in mind, only what you sell to your client. It means that if you do some refactoring, split your application in microservice, this tests shouldn't move if the functionality hasn't change. You can do this tests with Behat, but I prefer Codeception as you can include code coverage metrics and mix it with other tests suite coverage. This tests use WebDriver with a Chrome headless and Selenium. (and are really slow, but they are the most important tests IMO)
This are the based tests suite I'm having all the time. After that it depends on the project, I can had this 2 other tests suites :
API Tests : when you split your application with front part (react, angular, vue...) and a back part, this suite will only tests the back/API part, there I'm using PhpBrowser, faster than WebDriver and enough as I don't need to tests UI.
Functional Tests : I'm using this tests only to tests specific parts of my application which can not be covered by previous tests suite, or when there is a module which is so complex that I want to have a dedicated tests suite (like VAT calculation or transport fees calculation where there can be a lot of different cases). I'm also using this tests suite to check how to handle 3rd party error (like what happen when this payment API is down)
As I said, this is the main configuration I'm using, but you can do whatever you want. This needs to feet with the way your team is working and the requirements of your project. Codeception is a very flexible testing tool, predefined tests suites are only examples.