Simple Test Automation Strategy

25 Jan 2017

Test Automation Strategy

Below is a simple test automation strategy with core principles, practices and smells that can be applied to your project. This is obtained from Xunit Test Patterns book. The strategy is divided into five parts:

• Development Process: How the process followed for development affects the testing
• Customers Tests: It will give a clear representation of how the product should like
• Unit Tests: Helps to develop the design incrementally and helps to tests the code thoroughly.
• Design for Testability: The patterns that make the design easy to test and reduce the cost for test automation.
• Test Organization: How the testmethods and testclasses can be organized?

Development Process:

• Writing tests first has many advantages. It gives us a agreed upon definition of what success looks like
• TDD helps to develop the design of the software incrementally.
• It also helps to test the business logic without depending on the database layer.

Customer Tests:

• Writing customer tests first will gives us a definition of how the product should look like.
• Then they can be automated using scripted tests or data-driven tests. Scripted tests are hand written scripts to test the functionality of SUT. Data-driven tests are used to avoid duplication. When you have a set of tests which differ only with the input passed to it, then you can use data-driven tests. Recorded tests can also be used for automating the tests, if you are refactoring a existing application.
• Customers tests can become too long and obscure and tend to not provide very good Defect localization. This should be avoided.
• Well written tests can also act as documentation for the product.
• Every tests should have a Fresh Fixture before its run, which will avoid Interacting tests.
• The dependency of tests on other applications can be removed by using Test doubles.

Unit Tests:

• Unit tests can be effective only if it is fully automated.
• A Test case should only test a single condition in the SUT to provide Defect Localization.
• A Test case should clearly describe the four phases(Setup, Exercise, Verify, Teardown) to act as documentation for the product.
• A delegated setup or teardown should have descriptive names for the methods.
• Each test should be self checking test. In-built assertion checks can be used to do self-checking. If multiple tests share the same assertion check, it can be delegated to a method with a descriptive name.
• Indirect inputs to a SUT can be tested using Stubs and indirect outputs to a SUT can be tested using Mocks.

Design for testability

• Using TDD, you can develop a design which can be easily testable. Following a layered architecture will help to test the product in a much better way. The dependencies can be replaced with Test Doubles to avoid slow tests because of Disk I/O or Network requests.

Test Organization

• When the number of tests become very large, it becomes very difficult to maintain the tests properly. The tests can be organized using a Test Class per fixture or Test Class per feature. Test class per feature will allow to declare the setup for the fixture at one place.

Mocking

16 Jan 2017

Test Doubles

There are four types of test doubles

• Dummy Object
• Stubs
• Mocks
• Fake Object

Dummy Objects

• The Dummy Objects are used when there is a requirement for a object(will call it first object) to exist to create a different object(Will call it second object). The only purpose of the first object is for creating the second object. If instantiating the first object is expensive, then a Dummy Object can be used in its place. The Dummy Objects act as placeholders.

Stubs

• The inputs to a SUT can come from other forms different from the input parameters. They can be from other objects. If the SUT calls another object and decides the next action based on the outcome of the call to the other object, then the SUT is said to be getting input from the other object. If instantiating the other object is a expensive operation, then you can use stubs.

• Test Spy can be used to spy an object and verify a certain operation is performed on a object. It can be used to verify indirect outputs.

Mocks

• The Mocks can perform both operations which Stubs and Test Spys perform.

Fake Object

• Fake Object can be used to instantiate a simpler version of a object rather than a real expsenive one.

Mocking

Mockito

• A Mocking Framework in Java

Mock Server

• A Mocking Framework for http/https servers.

jUnit

14 Jan 2017

jUnit Test Framework

Core Classes:

• TestCase: All the testclasses extend this class. This class contains the setup, teardown methods
• TestSuite: Allows you to group a bunch of tests and run them by passing just the TestSuite object to the TestRunner.
• TestRunner: Allows you to trigger the test run.
• TestResult: Stores the test results
• Assert: Provides methods to do self verification.

Linux Essentials Certification

27 Dec 2016

Linux Essentials Certification Topics

• Open source software and linux open source philosophy.
• Finding your way on Linux
• Power of command line
• Understanding Operating System
• Security and file permissions in Linux

Nginx

24 Dec 2016

Notes on working with nginx web server (on CentOS 7)

1. Installation

Prerequisite: Add the nginx epel repo to the system.

• Create a file named nginx.repo under /etc/yum.repos.d/ directory and add

  [nginx]
  name=nginx repo
  baseurl=http://nginx.org/packages/OS/release/$basearch/
  gpgcheck=0
  enabled=1
  

  The OS should be linux distribution. In my case, it is centos and the release should be 5,6,7 for 5.x, 6.x, 7.x resp

Run sudo yum install nginx.

• This will install nginx on the system.

2. Directory Structure

The directory structure for nginx is

• Configuration directory: /etc/nginx/
• Default Configuration file: /etc/nginx/nginx.conf
• Virutal Host Configuration file: /etc/nginx/conf.d/
• Custom Configuration file: /etc/nginx/conf.d/
• Logs(Access and error logs): /var/log/nginx/
• Default Virutal host files: /usr/share/nginx/html/