What is testing?

Question

PHP

There are unit tests, functional tests, integration tests, and acceptance tests. Where can I read about all this to have at least some idea

Answer 1

In general, a wiki can be a start, and then delve into the literature. Here's a short description, the purpose of which is more to provide keywords for search.
Modular, they are also unit tests, designed to test individual modules / classes. Their essence is that we test the behavior of only one class at a time. If a class refers to instances of other classes, we mock them. That is, we slip them a fake class that has the same interface, but inside there is not an implementation of methods, but a check whether the method was called, with what arguments, how many times it was called, etc. Also, mock methods can return stubs (stubs), some data hardcoded for some case. That is, if we write a class for working with a database, a socket server, etc., we need a connection to the database, sockets, etc. wrap it in classes so that you can then replace this good with mocks. If you have real work with the file system or something like that in your unit tests, then this already smacks of integration tests. You can read more in the phpunit documentation. There is also such a development methodology as TDD, I advise you to read "Extreme Programming" by Kent Beck in this vein.
I want to note right away that unit tests are good, but only an ordinary PHP developer rarely writes something worth covering with unit tests. It takes a lot of time to support them, and the requirements of customers often change. As a result, the tests begin to comment and there is zero sense from them. But if you are writing a component/library, then unit tests are required (well... not exactly, but desirable). So if I were you, I would focus on the first stage on integration and acceptance tests.
Integration testing - testing several modules in conjunction. That is, we test our component or its self-sufficient piece in real conditions. If this component is for working with files, we allow it access to files. If the database - then we give a real connection to the database. And we can block something. As they say, it depends on the task. Let's say an appeal to third-party apishkas should be mokat and stabilized. The main purpose of these tests is to make sure that the modules work together well. This is especially important when modules are written by different people.
Functional testing is testing the entire application as an assembly. If this is a REST API, then real methods are pulled through curl, more or less real requests are sent, and responses are validated. If a web page, then these are UI tests with silent/phantom.js/zombi.js or, if we don’t need to test js as well, just curl + which virtual browser on the same php. In general, for good, functional tests do not allow any mocks, etc. but again, if you really want it, you can (again, turning to third-party services, over which we have no control).
But the reality is that covering a project with UI tests is not very convenient. Firstly, UI can change, but they also need to be supported. Second, it's boring. In the third, tests can simply fall ... so they took it and fell. And then it starts, so, the tests fell again ... what fell there? Oh, don't worry, you can release it. Also, on large UI projects, tests are worked out for a long time, for a very long time, some of them are simply driven at night. There is not much sense from tests with this approach, because the developer should know that something has broken as quickly as possible. And so he comes, sees that the tests are red again, repairs these red tests, and starts ... waits ... half an hour passes, for example, and somewhere else it fell off ... In short, you understand.
Acceptance testing - essentially the same functional tests, but served in the context of feature specs. If you have ever worked with a QA department, you may have heard about such things as acceptance criteria. That is, this is the checklist that the tester must check to make sure that everything is fine. Based on this checklist, you can write functional tests. There are also tools like Cucumber/Behat that allow you to write specifications in steps. In this case, the specifications for these tools can be written by QA and you just implement steps for them. That is, the layer between "acceptance criteria" and ready-to-run tests is reduced. Moreover, the steps can be reused, combined, there are a lot of steps ready, you only need to provide the steps that prepare the system (load / generate fixtures, etc.). In short, beauty and convenience. But slower than integration ones, but not as rigid as functional ones, due to this they are easier to maintain. QA is written for a spec, we implement tests for this spec, we write code for tests, the tests are green - the functionality is ready.
Well, there are all sorts of terms like a pyramid of tests, etc. They say it is better to have a lot of unit tests, a little less integration and few functional ones. Then the tests run faster, and covering everything and everything with functional tests is usually overkill.
Well, again, there is such a thing as common sense. Some things, let's say, can be completely scored and not covered by tests, some are worth covering. Some are not complete, some are covered as much as possible... Let's say testing the UI (exactly how it looks, where which element is) is generally pointless. This takes a lot of resources. Although there may be projects where this is justified.
In short, read about TDD and ATDD (you can also touch on BDD, but it depends not only on the programmer, managers, the customer or the product owner should also be involved, in fact this approach works well within the framework of some kind of product, freelancing and outsourcing rarely seen), Continious Integration and Continious Delivery.

Answer 2

>
unit tests
> functional
tests (WTF? Oh, right )
> integration tests >
integration tests
> and acceptance tests.
acceptance tests
> Where to read about it all in order to have at least some idea
I had some trouble guessing what "unit tests" were, the rest, it seemed, was obvious. You can read it on the English web. Yes, there, at least, on StackOverflow, I found there how functional tests differ from unit tests, and if you didn’t ask a question, I would have died an ignoramus.