Wouldn’t it be simpler if you just automatically tested the final app or site? The browser opens the website, the script moves the mouse, clicks the items and starts testing the final product?
These tests are called E2E tests and they are very useful for testing the final product and seeing if everything works. The only downside is that they are slow to run and often require a specific environment that needs to be set up before you can run the tests. That setup process can be pretty complicated for some projects and running the tests locally is pretty time consuming (That is where unit tests come into play).
But you are right it is sometimes easier to just test the application using E2E and integration tests since they require less mocking and still give you a pretty good idea of the current application status.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Also mocked tests won't depend on the 3rd party service from being up as your tests might fail when it is down or just when your network is slow.
Mocking also is sandboxed. If you frontend app needs to post to Twitter and you have 100 cases to test against the API using good and bad data and various made up user profiles, then a mock will mean you don't risk actually creating a tweet (or buying a product or whatever your app does). And will work without an API key.
It just means you have to keep your mock close to the real interface.
I have read a TDD book and it has a nice section on when to mock and when not too, so it depends on what you want to achieve
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.
Wouldn’t it be simpler if you just automatically tested the final app or site? The browser opens the website, the script moves the mouse, clicks the items and starts testing the final product?
These tests are called E2E tests and they are very useful for testing the final product and seeing if everything works. The only downside is that they are slow to run and often require a specific environment that needs to be set up before you can run the tests. That setup process can be pretty complicated for some projects and running the tests locally is pretty time consuming (That is where unit tests come into play).
But you are right it is sometimes easier to just test the application using E2E and integration tests since they require less mocking and still give you a pretty good idea of the current application status.
Indeed.
Also mocked tests won't depend on the 3rd party service from being up as your tests might fail when it is down or just when your network is slow.
Mocking also is sandboxed. If you frontend app needs to post to Twitter and you have 100 cases to test against the API using good and bad data and various made up user profiles, then a mock will mean you don't risk actually creating a tweet (or buying a product or whatever your app does). And will work without an API key.
It just means you have to keep your mock close to the real interface.
I have read a TDD book and it has a nice section on when to mock and when not too, so it depends on what you want to achieve