Beginner’s Guide To Software Testing — Part-3

“Even bad code can function but if it isn’t cleaned it can bring a development organization to it’s knees” — Robert C. Martin

Quoted above is a line taken from one of Robert C. Martin’s books (Clean Code) that emphasizes the importance of clean code.
In this blog, we would be taking a look at a few design patterns and principles that would help us move in the direction of writing cleaner code and understanding why it is important.

Patterns and principles :

Design patterns

A design pattern is an approach to architect source code in a certain way and make it more organized. Certain advantages of implementing design patterns are:
1. Increase readability.
2. Reduce lines of code changes in your source code whenever a bug or a new feature addition needs to be done.
3. Help in fastening the software development process by providing the benefits of already tested patterns.

Classifications of design patterns :

Creational: Deal with the way that objects are created. It helps increase reusability and flexibility.

Structural: Help us with class and object composition, i.e, they help understand how classes and objects can be placed while retaining code flexibility.

Behavioural: Help describe the communication between these objects.

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides well known as the Gang of four (GOF) have collectively authored a book titled “Design Patterns — Elements of Reusable Object-Oriented Software” where they demonstrate the concept of design patterns in software development in detail.

AAA pattern

AAA is a simple pattern for arranging and formatting code that we use while writing unit tests.

1. Arrange: Prepare the prerequisites and set up testing objects for your test.

2. Act: Perform the actual work of the test.

3. Assert: Verify the result.

SOLID principles

SOLID principles are 5 principles introduced to us by Robert J. Martin (Uncle Bob) and Michael Feathers that help us write effective and manageable object-oriented code.

● S (Single responsibility principle): One class should have one and only one responsibility.

● O(Open/Close principle): Software components should be open for extension but closed for modification.

● L (Liskov Substitution Principle): Derived classes must be completely substitutable for their base classes.

● I (Interface Segregation Principle): Clients should not be forced to implement unnecessary methods which they will not use.

● D (Dependency Inversion Principle): Depend on abstractions, not on concretions.

DRY principle vs DAMP principle

DRY principle: DRY stands for “Don’t repeat yourself “. This principle aims to reduce repetitive code and reuse existing code as much as possible.
It is easier to maintain one copy code than multiple copies of the same code. Hence implementing the DRY principle would save a lot of time and maintenance effort.

DAMP principle: DAMP is an acronym for “Descriptive And Meaningful Phrases”. The purpose of this principle is to increase readability by writing descriptive code. It also in turn saves maintenance time and effort which it would otherwise take to understand the code.

Though these two principles may come across as contradictory to each other, DRY and DAMP principles are equally important, and good code would imply a balance of both.

TDD vs BDD

TDD (Test-Driven Development ): It is a software development process that includes test-first development which means that test cases are first written for the application functionalities before writing the production code.
TDD helps in giving faster feedback and exploring bugs at an early stage.

BDD(Behavioural Driven Development ): BDD is a software development approach that emerged from Test-driven development(TDD).
In this approach, software user requirements are given in the form of human-readable descriptions for software tests.
Cucumber and Specflow are two testing frameworks that support BDD.

Like anything else, mastering the skill of writing clean code too would take time, patience, and practice. Implementing these patterns and principles in our code on a daily basis would help us get there gradually.

This brings us to the end of our “A Beginner’s Guide To Software Testing” series.
You can find the reference to previous blogs of this series at A Beginner’s Guide To Software Testing - Part 1 and Part 2.

Hoping this has helped you start your journey into the field of software testing.

Happy reading! 😄