You probably shouldn't mock the database
-
To keep unit tests fast and isolated, the data access layer is often tested using a mock of the database. But are unit tests and mocks actually a good choice?
It's trying the best it can
-
To keep unit tests fast and isolated, the data access layer is often tested using a mock of the database. But are unit tests and mocks actually a good choice?
It's trying the best it can
Quote:
A real instance of the same database as used in production can be launched within an integration test, which significantly minimizes the differences between the testing and production environments.
"To Dream the impossible Dream" I've been begging for this for years and been told no every time, to much PII. But then again we ONLY see some of the bugs with client data.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
Quote:
A real instance of the same database as used in production can be launched within an integration test, which significantly minimizes the differences between the testing and production environments.
"To Dream the impossible Dream" I've been begging for this for years and been told no every time, to much PII. But then again we ONLY see some of the bugs with client data.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
That's the advantage of small teams... In a previous job, I started a routinary process to backup the servers in images every 6 months periodically, the week before a rollout, the day before a rollout, the day after the rollout and a week after the rollout... Not only I could roll back if something didn't work fine, but I could get one of the backups running in a VirtualBox in an Offline PC and test with real data (not necessarily up-to-date, but still a complete real set) in a controlled environment. Being able to do my job correctly was more important for me (and my customer) than burocrats half a world away. So I just did as the quote says: "Better to ask for forgiveness than to ask for permission"
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
That's the advantage of small teams... In a previous job, I started a routinary process to backup the servers in images every 6 months periodically, the week before a rollout, the day before a rollout, the day after the rollout and a week after the rollout... Not only I could roll back if something didn't work fine, but I could get one of the backups running in a VirtualBox in an Offline PC and test with real data (not necessarily up-to-date, but still a complete real set) in a controlled environment. Being able to do my job correctly was more important for me (and my customer) than burocrats half a world away. So I just did as the quote says: "Better to ask for forgiveness than to ask for permission"
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
That can be an issue under a data protection regime, where developers generally shouldn't have access to real data except in the context of resolving issues. In such environments, great care must be taken to scramble any data that may include personally identifiable information or commercial information.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
That can be an issue under a data protection regime, where developers generally shouldn't have access to real data except in the context of resolving issues. In such environments, great care must be taken to scramble any data that may include personally identifiable information or commercial information.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
shouldn't have access to real data except in the context of resolving issues
And that's exactly the point. That many bugs or fixes can't be found without the real environment.
Rob Grainger wrote:
great care must be taken to scramble any data that may include personally identifiable information or commercial information.
I always take care. Additionally, that was before the GPDR (or however it is called in english) was activated, the server / data was in India and there were no personally identifiable information, relevant comercial information was very low (and nothing out of the scope of my work).
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.