Unit tests vs Automation testing

Question

I'm a C# developer & never worked before on either unit tests or Selenium browser test automation.

For a current assignment, there is an existing Visual Studio solution that has a project that does test automation. This solution has no unit tests.

For e.g, there is a form on the live site that captures customer data. This Selenium VS project on build, will auto open the browser, fill the form fields with random values, click on submit and verify the next steps like 'Thank you screen', database entries etc. (These test cases are created by developers & not by QC).

This is not unit test, but more of how a QC will test after the development is complete. right?

For someone who never worked on tests before, one advantage I see is, each time the code is deployed to a new environment like STG, UAT, etc, the developer can run this project by changing the URL/connection string, and it will execute all the test cases, saving time and like a regression testing too.

Is this a good approach to use this kind of testing instead of conventional unit tests. If not, what major advantage/disadvantage has one model over the other.

Answer 1

No, it is not a good approach. It is actually a terrible and common one. I would say it is a testing anti-pattern.

End-to-End tests like you describe are high-effort, low-value and have high risk of breaking when making code changes. The main issue here is that lots of software has it's tests written after the coding is complete, and adding stable and fast automated tests is often impossible. And end-to-end tests are often the only real option.

Instead, you should architect your software so that it can be excersized by big suite of fast, independent, isolated and business-focused "unit" tests. Then have few "integration" tests that stress the system's interactions with it's boundaries, like databases and services. And only have few end-to-end tests as form of smoke tests that the application as a whole is not behaving completely wrong (eg. not starting up). This is the standard testing pyramid : https://martinfowler.com/bliki/TestPyramid.html

And let me stress it once more: Achieving this is not possible when adding tests once you are finished coding. It is necessary you architect your code to enable writing fast automated tests against it. Best way I know how is through Test-Driven-Development. And if you want to add good automated tests to existing codebase, it will often require extensive refactoring and reengineering to enable that.

Answer 2

End-To-End tests have the following benefits

• They are very close to what the end user sees (often they directly test what the end user sees). They can directly test the fitness for purpose for the product user.
• They test thousands of lines of code per test
• They test the environment the product is deployed into

So they do a couple things unit tests can't do, and they test a lot of code. They don't replace unit tests. However, if your product has no tests at all, end-to-end tests can be a great way to introduce some test coverage.

I disagree with the previous poster they are high-effort and low-value.