Original filename: ImproveYourUnitTestsbyUsingChemicalBonds.pdf
This PDF 1.5 document has been generated by / Skia/PDF m52, and has been sent on pdf-archive.com on 07/05/2016 at 12:50, from IP address 109.64.x.x.
The current document download page has been viewed 310 times.
File size: 435 KB (7 pages).
Privacy: public file
Download original PDF file
Improve Your Unit Tests by
Using Chemical Bonds
In software engineering, a critical part of the development is to test your product. The most low level
of testing is Unit Test, in
which individual units of source code
One of the main goal of Unit Test is to find if there
is a problem at an early stage, before production stage, but there is a catch: which Unit Test to write, and how many?
How do we cover all the depths of code? In order to achieve this goal, we suggest to look at Unit Tests, at the code
being tested as a chemical organism which made of chemical bonds, which in turns allowing us to split and refactor
Unit Tests into the logical atom.
Before we continue, we need to cover some basic and core concepts which will allow us to
demonstrate the idea;
Intramolecular Chemical Bonds:
Strong chemical bonds are the intramolecular forces which hold atoms together in molecules. A
strong chemical bond is formed from the transfer or sharing of electrons between atomic centers and
relies on the electrostatic attraction between the protons in nuclei and the electrons in the orbitals.
1. Ionic Bond Ionic bonding is a type of electrostatic interaction between atoms which have a
large electronegativity difference. There is no precise value that distinguishes ionic from
covalent bonding, but a difference of electronegativity of over 1.7 is likely to be ionic, and a
difference of less than 1.7 is likely to be covalent.
2. Metallic bonding In metallic bonding, bonding electrons are delocalized over a lattice of
atoms. By contrast, in ionic compounds, the locations of the binding electrons and their
charges are static. The freelymoving or delocalization of bonding electrons leads to classical
metallic properties such as luster (surface light reflectivity), electrical and thermal
conductivity, ductility, and high tensile strength.
3. Covalent bond Covalent bonding is a common type of bonding, in which the electronegativity
difference between the bonded atoms is small or nonexistent. Bonds within most organic
compounds are described as covalent. See sigma bonds and pi bonds for LCAOdescription of
A polar covalent bond is a covalent bond with a significant ionic character. This means that the
electrons are closer to one of the atoms than the other, creating an imbalance of charge. They
occur as a bond between two atoms with moderately different electronegativities and give
rise to dipoledipole interactions. The electronegativity of these bonds is 0.3 to 1.7.
There are four basic types of bonds that can be formed between two or more (otherwise
nonassociated) molecules, ions or atoms. Intermolecular forces cause molecules to be attracted or
repulsed by each other. Often, these define some of the physical characteristics (such as the melting
point) of a substance.
1. A large difference in electronegativity between two bonded atoms will cause a permanent
charge separation, or dipole, in a molecule or ion. Two or more molecules or ions with
permanent dipoles can interact within dipoledipole interactions. The bonding electrons in a
molecule or ion will, on average, be closer to the more electronegative atom more frequently
than the less electronegative one, giving rise to partial charges on each atom, and causing
electrostatic forces between molecules or ions.
2. A hydrogen bond is effectively a strong example of an interaction between two permanent
dipoles. The large difference in electronegativities between hydrogen and any of fluorine,
nitrogen and oxygen, coupled with their lone pairs of electrons cause strong electrostatic
forces between molecules. Hydrogen bonds are responsible for the high boiling points of
water and ammonia with respect to their heavier analogues.
3. The London dispersion force arises due to instantaneous dipoles in neighbouring atoms. As
the negative charge of the electron is not uniform around the whole atom, there is always a
charge imbalance. This small charge will induce a corresponding dipole in a nearby molecule;
causing an attraction between the two. The electron then moves to another part of the
electron cloud and the attraction is broken.
4. A cation–pi interaction occurs between a pi bond and a cation.
As you can see from the definition above, a unit test checks other piece of code, now comes the
questions; how small should the “unit of work being tested” be? When tests fails, are there any ways
to find the root cause leading to it? In order to achieve those goals, we will suggest two approaches
which rely on chemical bonds:
1. Reviewing the existing unit tests and applying connections between them using chemical
2. During development stages, mapping code sections relations and reflecting them to chemical
Applying Connections Between Existing Unit Tests Using Chemical Bonds
This approach can be applied on existing unit tests repository
. The vision behind this approach to
classify bonds between unit tests which will allow you to group them together using common
chemical bonds. Each group can be referred as a molecule and every unit test part of this molecule
can be considered as an atomic cell. By embracing this approach we can achieve a better picture
when we encounter unit tests’ failure which will allow us to find root cause (i.e. the concealed bug).
In order to demonstrate this implementation of software testing methodology we will try to show
how it can be effective during development of banking system. Let us define some predetermined
entities and basic operations:
1. Bank account
2. Bank client
Create new account
Money transfer between account
Client login to the system
Common unit tests:
ID number of client is valid
Client's phone number is valid
account number is valid
amount of money to transfer is valid (is number and not negative)
transfer amount of money into an invalid account
transfer amount of money into a valid account
withdraw money from empty account
withdraw money with sufficient amount
Password fit the standard
Login with invalid password
trying to create an already existed account
trying to create a new account
check balance is correct after deposit
check balance is correct after withdrawal
Connections Between Unit Tests
During the process of analyzing the connections that can be among given unit, unit tests can be
described as below:
1. One unit test is obligatory for a given set of unit tests describing a process tested but that
specific is also independent and can be ran by its own.
Example: taking the atomic unit test “account number ID is valid”, it is obligatory for 2
processes tested: transfer amount of money into an invalid account and withdraw
money with sufficient amount.
2. Two sets of testing sharing a subset of unit tests.
■ withdraw money with sufficient amount
■ check balance is correct after deposit
These too testing processes share the following subset of unit tests: login
succeeded,Login with invalid password and so on.
3. During the process of testing the failure of a specific test can directly imply that a greater set
of tests will fail too.
xample: while testing transfer amount of money into an invalid account,
calling the unit test that check validity of a client account, if the test fails we could
explicitly say that also withdraw money with sufficient amount will fail too.
4. One unit test can be autonomous and be used by a various of testing processes.
5. Two or more unit tests can be run only together in a certain order and can not be separated.
Example: while testing the creation of a new account, we first must check
client phone number and if password fits the standard.
Unit Test Categories
1. Security Tests Tests that check the vulnerability of the code for security attacks and security
2. Validation Tests Tests the input of the functions.
3. Functional Testing Test the behavior of a specific functionality under various conditions.
4. Black Box Testing Tests the code without knowing it’s internals.
5. White Box Testing testing that takes into account the internal mechanism of a system or
component (IEEE, 1990). Whitebox testing is also known as structural testing, clear box
testing, and glass box testing (Beizer, 1995). The connotations of “clear box” and “glass box”
appropriately indicate that you have full visibility of the internal workings of the software
product, specifically, the logic and the structure of the code.
Reflecting chemical bonds on the code being tested
During development stages, we need to find out which piece of code should we test, in order to do
that, we suggest looking at the code being tested as an chemical organism that is connected by
chemical bonds. The main idea of this approach is to give an analogy between `chemical bonds` and
`pieces of code`, so that we can take the properties of chemical bonds and reflect them on the `piece
of code` in question. By this analogy we can get an idea of how to split the test units even further and
also make a logical connection between already exists unit test, e.g. if testa fails, which test code in
bond with code tested in testb, testb itself also shall fail.
The analogy in this approach is abstract and can be adopted as the implementer wishes it to fit its
specific domain. Since there are two categories in chemical bonds; intramolecular (inside a molecule)
and Intermolecular (between molecules), we can assign those categories between elements in our
code such as function members and classes.
SimPy is a processbased discreteevent simulation framework based on standard Python. Alongside
its source code it has a large amount of unit testing that tests many features and methods in the
implementation. To demonstrate the case shown in this article we examined those unit tests and the
code sections they are testing, Changed the source code in order to make the chosen unit test to fail,
ran the tests and logged for every unit test we examined the derived unit tests that failed. After
finishing altering the code and logging failed tests we loaded it as a graph where you can see each test
causing which other tests to fail. So the algorithm we took in order to do so was:
Choosing a basic, infrastructural looking test.
Change the product source code to make the chosen unit test to fail.
Running all the unit tests to see if other tests has failed
If no other unit test fails but her its an autonomous unit test living by it self
If another unit test has failed this means this test is shared with other tests.
Each run of the unit tests produced a “JUnit” XML which describes which tests passed and which
failed in a structural format. After choosing which test to fail, the XML output file name would match
the test in question (e.g by choosing ‘test_value’ to fail, the output file would be
‘test_value.fails.xml’). The name is important since it’s consider as metadata which will be need when
building the graph.
This demonstration handles
of a single library in
python called ‘SimPy’
The graph is built is the following manner; each output file (e.g test_value.fails.xml) is being read and
added to the graph as the roottest and it’s edges are the tests which failed alongside this test.
(implementation script of parsing the XML files can be found in case_study/to_graph.py)
* bold edges are arrowlike, directional from the nonbold to the bold.
Reflecting connections between Unit Tests can show how they may affect one another and provide
additional guidance when they might fail. The advantage of this graph is to make is easier to find the
roottest which might hold the core bug in question. For example, If in future change of the module
itself, some Unit Tests might fail, by checking those failures against the graph, we can identify the
roottest and trying to fix it first.
● outputs folder holds all the XML files which are used to produced the graph
● to_graph.py the script which reads the XML files and create the graphs (this script runs using
● graph_dots.dot the graph is a ‘dot’ format (textual base used by the linux command dot)
● output_graph.png the graph created by pygraphviz (displayed in this article)
● nonoverlap.dot.png the graph created by dot command (without overlapping between
● scaled.png the graph created by dot command with scale attribute to void overlapping
linux dot command
Book “The Art of Unit Testing, Second Edition” by Roy Osherove
Williams, Laurie. "WhiteBox Testing": 60–61, 69. Retrieved 13 February 2013