Automated Unit Testing vs GUI Automation

Question

Automated testing is any type of testing where you are using one piece of code / program to test another piece of code / program. This can be unit testing as described above, or it can be via a specific automation tool, such as TestComplete, QTP, Selenium, etc.Unit tests tend to be created and executed by the developer of the code in question, whereas GUI automation will more probably be carried out by a software QA specialist.

With regard to this certain questions come to mind.

1) Is it better to write automated unit tests using code or perform GUI Automation using Automated Test tools like QTP, Selenium?

2) In a SDLC lifecycle, what is the effort involved in writing Automated Tests using code versus GUI automation using Automation Test Tools?

3) Are their benefits of writing Automated unit tests using code and performing GUI Automation using Automation Test Tools?

Answer 1

The purpose of the unit tests and GUI automated tests are different. The unit tests (usually implement by developers) should verify vary input and output of one function that under the test. It may be implemented with help the mock system if required. The unit tests usually run fast and all such suite haven't take more than 1 sec. The GUI test are simulated the user behaviour (we often call them end to end tests) and may take much more time for the execution.

1. I wouldn't recommend write the unit tests with help of GUI automation because you want run them fast, rerun every time , be very stable and not be affected from other objects like browsers.
2. It is much easy to write the automated tests using some automation recording however usually it is much less stable than code that you will write by yourself using the appropriated API.
3. I am not sure that I follow you here but again the unit tests preferable write in code w/o GUI, the system test usually should be written with help GUI automation environment like Selenium.

Answer 2

Unit tests and automated tests via GUI serve different purposes. Moreover, high-level automated tests are not necessarily done via UI.

Have you seen a testing pyramid?

This is, of course, the ideal case, which rarely happens in the real life. But it's something to strive to.

Unit tests are easier to write. It might not be the case for the legacy code though. Code refactoring would be required to add unit tests if the code is not written with testability in mind. In this case, high-level tests via public APIs or GUI would be easier to write. But that's not necessarily the right thing to do.

Unit tests are faster to execute, thus the developer get the feedback quicker and can almost immediately spot if something is broken. As well, a well-written unit test makes is easy to diagnose the problem and quickly find a faulty line of code. With GUI test and high-level tests in general it takes more time to diagnose the problem. There's a higher chance of a failed test is just an environment issue or some other dependency problem.

Having all that in mind, the testing pyramid sums it all up pretty nicely. The earlier you can catch a problem, the better. Thus the majority of the test effort should go to unit testing. But there's always bugs that can't be caught on the "method level". So you move one level up, and that's where your integration tests shine. GUI tests can cover the E2E cases which are vital for the product, e.g. making sure the Login button actually exists and is clickable :D

To sum up, there's no simple answer on what is better, because they achieve totally different goals.