I have this, I know it's a general question, but I've been struggling with it for the last few days and it's getting in the way of my work.
I have a software written in .NET that has 2 parts
- The first part is the API
- The second part is an application with Azure Functions
The applications communicate with each other using a message broker. The application is kind of finished and of course I thought it would be nice to test it (yes I know, tests should be written continuously, but it is really a small application to play with)
I started with the tests, and of course it was easy at first because I got into unit tests. However, then I ran into a bit of a problem which I will try to explain. I read in many articles that there are component tests and integration tests and I guess I'm a bit confused. Let me give an example. In the first part I have a class that pulls data from a database, say Service1, and then I have a controller where there is an ednpoint item that calls Service1 and returns data.
Now there's a little bit of confusion that I want to check.
Component tests are inside one "service" and it is actually a test where I can still mock up a lot of things. I would use this if I wanted to write a test that Service1 pulls data from a database (either in memory or real) in order, for example. And the integration tests are actually already tests of the API itself, i.e. I can "bootstrap" the whole application and everything I need for example the db and test that the endpoint items return data from the db.
Or is this a wrong statement and the compoennt tests represent both - Service1 and communication with the db, and the API call itself. And the integration tests are actually tests between services i.e. the first part API and the second part Azure Functions?
I hope this is clear and that I'm not asking too stupidly. Thank you
This is a very subjective question, mainly due to (in my opinion and experience), the scope of these test methodologies being understood by individuals in different ways.
I find the scope of your test approaches are best decided as a team/business/group and then you can clear the fog around what "integration test" scope looks like for you and your systems under test. For example, Integration test can technically cover almost anything, and its scope can be massive if not decided on beforehand.
Though generally, if we look at theory, integration is where you will deal with mocked dependecies and the interaction between areas. So this would the DB communication, API calls etc.
Component would be, as defined by Martin Fowler, tests that are designed to ensure the service itself works as expected.
To add extra confusion, component can also be a subset of integration, but lets not go into that....
To summarise, I think you should sit down and decide what you determine Integration and Component means for you, and then begin to put tests into the relevant bucket! Sorry for the lack of concrete black and white answer, but dealing with definitions in software testing rarely is clear.