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.
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.