**Mocks aren’t equivalent to the integrations they replace.
True, but that is intentional. You can ensure that they are returning the right data via schema validation based on the contract of the service.
In a word, you can ensure that mocks return the same thing (that is, the same schema not same data per se) without the complexity of integrating with the real thing.
**If you mock a database client then you haven’t tested the integration with the real client. This means that your code may work with the mock but you will still need to do integration testing to make sure it works without mocks.
If you don't mock, then you have to set up your testing environment to speak to the real service. This requires extra maintenance, and when there is an issue (which is definitely not uncommon) it can be very confusing to know what needs to be fixed.
Without mocking, you need to add more configuration to your testing environment, increase your knowledge to know how the service works under the hood, and learn how to debug. This leads to change amplification, increased cognitive load, and unknown unknowns which are the three main causes of software complexity.
Lastly, if the connection with the database isn't working, you can catch that via manual testing in the browser, or by a "smoke test" before releasing to production. In both these cases, you can test the database connection implicitly. Integration tests don't need to test that every single connection works, just that everything is working as expected from the vantage point of the user.
**Feature Parity Is Not Feasible.
You can still have feature parity. Mocks can behave however you desire, and that means they can behave exactly like the real service.
However, the point of mocks is to not work just like the service. They should have the same signature and behavior but more sensible data.
**If you make a quick mock then it won’t return useful data. The more time you spend improving the mock the more useful the data will be. However it can never be a true representation.
A mock isn't supposed to be a true representation. It's meant to be more sensible and easier to work with. However, as mentioned above, you still can ensure that the sensible data is still valid data via schema validation.
**Mocks that aren’t used are a waste of time and effort.
Then delete them.
**If you mock out a database client and don’t use it then there is no point mocking it. This can occur if some code requires valid configuration to initialise but doesn’t use it.
Same as above. Also, you don't have to mock out a database client in its entirety.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Agree on everything, also adding that test automation, integration tests or unit tests are not meant to validate service availability, we have tools on any cloud service such automated health checks, monitoring tools and so on that are responsible for that.
If a DB gets downed you'll notice it by an instant notification and probably a trigger will restart that service before you can log into the dashboard.
On the other hand there are two ways to work with databases.
Code First vs Database First.
The ORM will handle one or the other depending on the initial setup.
If the project qualifies for that you'll set up database first and have some data guy building the best possible data structure, otherwise you'll probably use code first and let the ORM do the rest.
It is a [definition -> schema] process on one side or the other which is the reason I'd better use some seeders that match the possible data (according to the schema) and go ahead with that.
The ORM will also validate that the input data matches the schema and will throw an error if it's not the case and you can double-check that through backend unit testing.
Those seeders will be used in development always anyway, I expect people not to copy/export data from real clients stored in the secured production database into other environments for obvious reasons so on a way or another yes, you'll need mock data.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
**Mocks aren’t equivalent to the integrations they replace.
True, but that is intentional. You can ensure that they are returning the right data via schema validation based on the contract of the service.
In a word, you can ensure that mocks return the same thing (that is, the same schema not same data per se) without the complexity of integrating with the real thing.
**If you mock a database client then you haven’t tested the integration with the real client. This means that your code may work with the mock but you will still need to do integration testing to make sure it works without mocks.
If you don't mock, then you have to set up your testing environment to speak to the real service. This requires extra maintenance, and when there is an issue (which is definitely not uncommon) it can be very confusing to know what needs to be fixed.
Without mocking, you need to add more configuration to your testing environment, increase your knowledge to know how the service works under the hood, and learn how to debug. This leads to change amplification, increased cognitive load, and unknown unknowns which are the three main causes of software complexity.
Lastly, if the connection with the database isn't working, you can catch that via manual testing in the browser, or by a "smoke test" before releasing to production. In both these cases, you can test the database connection implicitly. Integration tests don't need to test that every single connection works, just that everything is working as expected from the vantage point of the user.
**Feature Parity Is Not Feasible.
You can still have feature parity. Mocks can behave however you desire, and that means they can behave exactly like the real service.
However, the point of mocks is to not work just like the service. They should have the same signature and behavior but more sensible data.
**If you make a quick mock then it won’t return useful data. The more time you spend improving the mock the more useful the data will be. However it can never be a true representation.
A mock isn't supposed to be a true representation. It's meant to be more sensible and easier to work with. However, as mentioned above, you still can ensure that the sensible data is still valid data via schema validation.
**Mocks that aren’t used are a waste of time and effort.
Then delete them.
**If you mock out a database client and don’t use it then there is no point mocking it. This can occur if some code requires valid configuration to initialise but doesn’t use it.
Same as above. Also, you don't have to mock out a database client in its entirety.
Agree on everything, also adding that test automation, integration tests or unit tests are not meant to validate service availability, we have tools on any cloud service such automated health checks, monitoring tools and so on that are responsible for that.
If a DB gets downed you'll notice it by an instant notification and probably a trigger will restart that service before you can log into the dashboard.
On the other hand there are two ways to work with databases.
Code First vs Database First.
The ORM will handle one or the other depending on the initial setup.
If the project qualifies for that you'll set up database first and have some data guy building the best possible data structure, otherwise you'll probably use code first and let the ORM do the rest.
It is a [definition -> schema] process on one side or the other which is the reason I'd better use some seeders that match the possible data (according to the schema) and go ahead with that.
The ORM will also validate that the input data matches the schema and will throw an error if it's not the case and you can double-check that through backend unit testing.
Those seeders will be used in development always anyway, I expect people not to copy/export data from real clients stored in the secured production database into other environments for obvious reasons so on a way or another yes, you'll need mock data.