Google’s Philosophy and Core Principles
- Focus on the user and all else will follow.
- It’s best to do one thing really, really well.
- Fast is better than slow.
- Democracy on the web works.
- You don’t need to be at your desk to need an answer.
- You can make money without doing evil.
- There’s always more information out there.
- The need for information crosses all borders.
- You can be serious without a suit.
- Great just isn’t good enough.
- Mimic user interactions in the form of scripts.
- Run in form of a test.
- Acts just like a user.
Test a complete system end-2-end
Feature:
- Slow - they take seconds to run
- Fragile: they often fail by numerous reasons
- Not scalable - it is impossible to pass through all paths in any application but the very smallest
- Great for verifying that the most important flow through the application works
Thus, User more sparingly. Used for really important end-to-end style smoke tests
In google, every night:
- The latest version of the service is built.
- This version is then deployed to the team's testing environment.
- All end-to-end tests then run against this testing environment.
- An email report summarizing the test results is sent to the team.
- Mimic the http calls
- Compared with UI test, it tests similar functionality in a slightly different way.
Feature:
- slow - they take seconds to run
- brittle - there are many reasons to why they fail
- not scalable - it is impossible to pass through all paths in any application but the smallest
Great for verifying that important components are properly connected
Used for Web services, tell us there are problems but can not tell us where
Focus on what the unit of code is doing, not what its dependencies do.
- fast - they take milliseconds to run
- stable - there is only one reason to why they fail
- scalable - it is possible to pass through all paths in any application
- Isolates Failures
- great for verifying that implementations you later depend on actually work
Feature:
- Highly precise
- Highly efficient
- Miss bugs that can sometimes only occur when you hook things up
Rely on the unit test for the bulk of our automating testing.
Everything it touches should be done in memory; this means that the test code and the code under test shouldn't:
- Call out into (non-trivial) collaborators
- Access the network
- Hit a database
- Use the file system
- Spin up a thread
If we "focus on the user (and all else will follow)," we have to ask ourselves how a failing test benefits the user. Here is the answer:
| Stage | Failing Test | Bug Opened | Bug Fixed |
|---|---|---|---|
| Value Added | No | No | Yes |
Thus, to evaluate any testing strategy, you cannot just evaluate how it finds bugs. You also must evaluate how it enables developers to fix (and even prevent) bugs.
Bad testing design leads to :
- Higher maintenance costs
- Duplicate effort
- Pure waste
- Common language in teams
- Good rules of thumb, where and when to use different kinds of tests
- Save time and effort
Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests.
- Contract Testing: A very good practice in micro-service architect.There are some solution for it. One of the most suitable one is a consumer-driven contract testing called "pact".
- If possible, keep your Test Automation in the same repo since you may need Mocking/Stubing plus versioning can be tricky. Also staying in the same repo could be a help for you CI/CD pipeline.
- Have a look at Microservice testing by M.Fowler. It gives good idea about different layers of Micro service testing.
Testing in isolation
Testing in production
consumer-driven contract process
pact