PDF Archive

Easily share your PDF documents with your contacts, on the Web and Social Networks.

Share a file Manage my documents Convert Recover PDF Search Help Contact



ImproveYourUnitTestsbyUsingChemicalBonds .pdf


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









Document preview


Improve Your Unit Tests by 
Using Chemical Bonds 
Introduction  
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.  

Core Concepts 
Before we continue, we need to cover some basic and core concepts which will allow us to 
demonstrate the idea; 

Chemical Bonds 
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 freely­moving 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 LCAO­description of 
such bonding. 
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 dipole­dipole interactions. The electronegativity of these bonds is 0.3 to 1.7. 
 
 

Intermolecular Bonding: 
There are four basic types of bonds that can be formed between two or more (otherwise 
non­associated) 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 dipole­dipole 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. 
 
 

 

Unit Test: 

 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 
bonds. 
2. During development stages, mapping code sections relations and reflecting them to chemical 
bonds  

Applying Connections Between Existing Unit Tests Using Chemical Bonds 
This approach can be applied on existing unit tests repository[1]
​​
. 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). 

Artificial Example  
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: 
Entities: 
1. Bank account 
2. Bank client 
3. ATM 
Operations: 
1.
2.
3.
4.
5.
6.
7.

Create new account 
Deposit money 
Withdraw money 
Money transfer between account 
Check balance 
Delete account 
Client login to the system 

Common unit tests: 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

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 
login succeeded 
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. 
Example:  
■ 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. 
E​
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 
standards. 
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). White­box 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 test­a fails, which test code in 
bond with code tested in test­b, test­b 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. 

 
Hands­On Example 
 
SimPy is a process­based discrete­event 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: 
1.
2.

Choosing a basic, infrastructural looking test. 
Change the product source code to make the chosen unit test to fail. 

3.

Running all the unit tests to see if other tests has failed 
3.1.
If no other unit test fails but her ­ its an autonomous unit test living by it self 
3.2.
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. 

Clarification:​
 ​
This demonstration handles ​
unit testing​
 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 root­test 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 arrow­like, directional from the non­bold to the bold. 

 
 

 

Conclusion 
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 
root­test 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 
root­test and trying to fix it first.  

appendix 
● 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 
python 2.7) 
● 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) 
● non­overlap.dot.png ­ the graph created by dot command (without overlapping between 
nodes) 
● scaled.png ­ the graph created by dot command with scale attribute to void overlapping 

 

Bibliography 





 
 

python­simpy ­ ​
https://simpy.readthedocs.org/en/latest/ 
python­networkx ­ ​
https://pypi.python.org/pypi/networkx/ 
linux dot command ­ ​
http://linux.die.net/man/1/dot 
Book ­ “The Art of Unit Testing, Second Edition” by Roy Osherove 
Williams, Laurie. "White­Box Testing": 60–61, 69. Retrieved 13 February 2013 ­ 
http://www.chaudhary.org/WhiteBox.pdf  


Related documents


improveyourunittestsbyusingchemicalbonds
engineering notes
datbiology russelldw
5070 w09 er
5070 s12 ms 22
5070 s06 er


Related keywords