Skip to content
August 24, 2012 / selenium74

Testing Philosophy

Through discussions between the QA group and developers at our corporation, it has become apparent that there are terminology and ideological differences between these two groups. This is compounded when an automation group begins testing. What exactly should the automation group work on? Who should be writing unit tests? What exactly are unit tests?! I will attempt to answer some of these questions, at least from the automation perspective. I would love to hear feedback on this, so please comment with your thoughts.

What is a unit test? According to Wikipedia, it’s “a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.” So… what does that mean? To me, a unit test is a test that tests a small module or class that ALSO can be run in isolation. A unit test is a test that mocks interactions with outside services, so that it can be run without network access, database access, etc.

OK, that seems pretty straight-forward. What then is a test that tests some small module or class but also hits external or internal services? This would be an integration test. The test is testing the INTEGRATION of the components, by testing their interaction.

So with those definitions out of the way, who should write unit tests? The developers of the code in question should. It also isn’t out of the question that they should be responsible for some integration testing. After all, how can they be sure that their code works as expected without seeing how it interacts with the rest of the system?

Well, if developers are to write unit tests AND integration tests, what should the QA automation group be doing? The obvious and not very helpful answer is, automating QA tasks. One example would be ensuring that some module on a web page got rendered correctly using a tool like Selenium. This module could be static content, or it could be populated by service endpoints. Tests through the front-end test essentially ALL parts of an application, from the database, to web services, to whatever caching procedure is in place, and potentially any CDN in place. Provided these tests are modular and well-designed, code reuse is high and benefit is high, too. If the tests run on a CI server whenever a build is performed, in addition to the unit and integration tests written by developers, many issues will be exposed before the code is ever deployed. Then, QA is free to hand test the things that aren’t easily covered via automated interactions with Selenium.

That all sounds fine and good, but what about tests that aren’t quite covered by the above? Well, the demarcation isn’t black and white, between QA automation and developers. This is when you will have to meet with the disparate groups, and come to an agreement on what makes the most sense in your organization. The first step is to get everyone on the same page and make sure the definitions between the groups are the same, and hopefully this post will prove helpful in that regard.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: