The terms in software world doesn't usually have a well regulated definition , it is more about understanding the concept and having an organised approach to testing than testing what ever comes to our mind.
so don't need to break your head over these definitions , just remember the below
One of the reliable definitions you can refer is from ISTQB glossary: https://glossary.istqb.org/app/en/search/
Unit Test
A test level that focuses on individual hardware or software
components.
so you can define what is component in anyways , it can be a class , an package, a library and so on.
Going too deep and finding the smallest component is not worth it so we considers a class or library as a unit and tests all the methods in the object works fine depending on your project.
Integration testing :
https://glossary.istqb.org/en/term/integration-testing-2#:~:text=integration%20testing,between%20integrated%20components%20or%20systems.
Testing performed to expose defects in the interfaces and in the
interactions between integrated components or systems.
Here again you can define what to integrate . so imagine you have 10 components and each component is integrated with each other components .
So if you try to test all this combinations , then you will spend all your time in testing than in developing something
so we don't test all the integrations we will test the integrated system as a whole ,
so in integration test we are testing a system of integrated components works fine, or the interface (API) that allows this integration works fine.
in the latest version of definition we have :
https://glossary.istqb.org/app/en/term/integration-testing-3
A test level that focuses on interactions between components or
systems.
they have removed the interface part , but i will like stick on to first definition as it makes more sense.
System Testing
A test level that focuses on verifying that a system as a whole meets
specified requirements.
Again system can be defined only by you on the context of your project . For example if your working with multiple agile teams. Each teams responsibility is to provide a delivery that is considered as a system for them
eg furniture is a system sitting on it , jumping on it is part of system testing
in your case if database is part of your team then DB+API+UI is your "system" , you will make sure this works as a whole.
but if your responsibility is to develop API+UI your system is (API+UI) not DB
System integration testing
A test level that focuses on interactions between systems.
eg Moving the chair into a house/room , so your checking how two system the "house" and "chair" works together
in your case:
if DB is handled by some other team , you are checking how "DB+API+System" work together
Summary:
- Don't worry much about definitions , testing is highly context
depended.
- The definition of component/unit, systems, integration etc changes according to your project
- You don't have to dissect your product into so many minute components , but to many reusable component , and test its re-usability.
- Don't worry too much on component integration because in lower level of abstractions there will be too many integrations you cannot test them all and you don't have to
- Tests the interfaces this interactions and tests the system as whole
- Concentrate more on business use case than just functionality