These are tests that validate the correctness of the code, from a features point of view (that is, does the software do what it should?). Functional tests need to validate that everything works as expected:

• Unit tests: Unit tests are the lowest level tests that we can write. These tests focus on the smallest units of code (for example, functions and classes). For example, we could write a unit test that checks a specific function or class. Unit tests assume that the system is a white box; this means that we know the inner workings of the system when writing the tests. These tests should work in complete isolation. This means that if the unit of code under test relies on other parts of the system, then these should be abstracted away in order to avoid side effects. This can be done using mocks and stubs. Unit tests are usually the cheapest to develop and maintain and the fastest to execute, compared to other types of tests.
• Integration tests: Integration tests are higher-level tests that we can write to verify that different parts of our system integrate as they should with other parts and that, as a whole, they deliver the expected functionality. These tests only require some level of isolation; this means that we will focus on specific interactions and that we'll abstract away other ones depending on what we aim to test. Integration tests are often relevant for distributed systems. They're usually slower to execute than unit tests, simply because they need to do more setup work before executing.
• End-to-end tests: End-to-end (E2E) tests are higher-level tests that can be created in order to validate complex scenarios. Sometimes, user interface (UI) tests are performed by E2E tests, but it certainly isn't the only solution. Actually, UI tests can also be performed through unit tests. E2E tests are way above unit tests because they rely on the collaboration of all system parts, from the lowest-level units of code up to the UI layer. The user interface is usually harder to test because it tends to be much less stable than other parts: each modification to the interface will directly affect the tests, and so these are brittle. Generally speaking, E2E tests cost a lot more to create and maintain over time. Importantly, they're also usually much slower to execute.
• System tests: System tests are tests that consider the whole application as a black box and validate its behavior according to the requirements.
• Sanity tests: Sanity tests are tests that aim to provide some confidence about the overall system. They only aim to check the major features of the system to validate that they work as intended. Sanity tests are usually performed when there is not enough time to go deeper.
• Smoke tests: Smoke tests are similar to sanity tests because they also try to touch the main features of the system. The difference is that tests that are marked as smoke tests are the first ones to be executed for any new build. If any of those fail, then there's no need to go further; otherwise, the rest of the tests can be executed. Smoke tests are useful for avoiding useless quality assurance checks. In one sense, we can consider smoke tests as the bare minimum tests that should pass before the rest are even looked at.
• Regression tests: As their name indicates, regression tests are tests that we can write to ensure that some previously fixed issue does not resurface. Whenever we fix some important bugs, then we should consider writing a test case to validate that the software continues to work as intended. Whenever those tests get executed, they'll check whether there is any regression in the new code.
• Acceptance tests: Acceptance tests are used to decide whether a new version of an application is good enough to make it to production. Acceptance tests are detailed scenarios that represent concrete examples of interactions with the system to achieve business goals. Acceptance tests should ensure that of all the major parts of the system work as intended. In an ideal world, acceptance tests should also be automated and thus be part of the executable specifications. Such scenarios are not easy to write, but there are techniques that can help, such as feature mapping: https://johnfergusonsmart.com/feature-mapping-a-simpler-path-from-stories-to-executable-acceptance-criteria.