Art of unit testing: How developer should care about code quality

The Art of Unit Testing:
How developer should care about code quality
Dmytro Patserkovskyi

2 CULTURE
What is
SOFTWARE TESTING?

DIVE INTO THE HISTORY
3
Let’s look over the philosophy of software
testing 100 years ago.

DIVE INTO THE HISTORY
Debugging
4
Automated
Testing
Manual Testing
SUnit(1989)
JUnit(2001)
1970’s1950’s

DIVE INTO THE HISTORY5
Kent Beck: 1989: "Simple Smalltalk Testing: With Patterns"

”
Software testing it the complex of
techniques include the process of executing
a program or application with the intent of
finding software bugs.
6

PLACE OF UNIT TESTS
7
Let’s find place of unit tests in the ocean of
Software Testing.

AUTOMATION
MANUAL
PLACE OF UNIT TESTS8
DEBUGGING
SOFTWARE
TESTING

COMPONENT
INTEGRATION
UNIT
PLACE OF UNIT TESTS9
SYSTEM
AUTOMATION
TESTING

UNIT TESTS
10
Unit tests – part of code that are designed
to ensure the smallest divisible pieces of
code (units or components) are working
the way they were intended.

UNIT TESTS
@BeforeClass
public void testBeforeSuite() {
prepareMailService();
}
@Test(groups = "mail")
public void testEmailService() {
MailService service= generateMailService();
Assert.assertNotNull(service);
}
@Test(dependsOnMethods = { "testMailService" }, groups="mail")
public void testSending() {
Assert.assertTrue(service.sendMail(subject, message));
}
11 Test
Configuration
Preparations
Assertions
Grouping

UNIT TESTS
Test - part of code, that check logic of another part of code.
Assertions - mechanism for checking results of lome logic,
defines if our unit test will be success or failed.
Configuration - all attributes and properties of test.
Preparations - part of code, that prepares state and context for our tests.
12

UNIT TESTS
Grouping - associates unit tests into groups and suites. Each group or suite should
have common property or characteristic.
13
GROUP SUITE
Contains Methods
Depends on Groups
Annotations Config
Runs Separately
Contains Groups
Flex Configuring
Configuration in XML
Runs Separately

UNIT TESTS
Test Dependencies. If a dependent method is fail, all the subsequent test methods
will be skipped, NOT failed.
}
@Test(dependsOnMethods = { "testMailService" }, groups="mail")
public void testSending() {
}
15

UNIT TESTS
Parameterized Tests. Run your single test for different data sets.
@DataProvider
public Object[][] smtpHosts() {
return new Object[][]{ {"smtp.host1"}, {"mail.host2"} };
}
@Test(dataProvider = "smtpHosts", groups="mail")
public void testSending(String host) {
MailService service= generateMailService(host);
}
16

UNIT TESTS
Rich @Before and @After configuration.
@BeforeSuite - @AfterSuite
@BeforeTest - @AfterTest
@BeforeGroups - @AfterGroups
@BeforeClass - @AfterClass
@BeforeMethod - @AfterMethod
17

PRINCIPLES OF UNIT TESTS
18
We know how to write units! Don’t we?

19
Principles of Unit Tests:
▹ Easy and fast to run
▹ Unit
▹ Simple
▹ Independent
▹ Checking all cases
▹ Isolate

ARCHITECTURE OF PROJECT21
Let’s imagine component for sending emails, and try to cover it with unit tests.
Services:
▹ MailService - service for sending emails. Based on Javax Mail.
▹ LogsStorage - service for collecting logs about mails sending and flushing it
to persistent storage.
▹ LogsMailService - service for work with emails and logs.

// Bad
public void testEmailSending() {
MailBuilder builder= new MailBuilder();
Mail mail = new MailBuilder().
.newMail()
.addSubject("my mail")
.addRecipient(firstRecipient)
.addRecipient(secondRecipient)
.build();
Assert.assertNotNull(mail);
Assert.assertEquals(EXPECT, mail.getSubject());
...
Assert.assertTrue(service.sendMail(mail));
}
22
// Good
@BeforeTest
public void initialize() {
service= generateMailService();
}
Assert.assertTrue(
service.sendMail(prepareMail())
);
}
Unit & Simple - each test covers one piece of code.

// Bad
public void testEmailLogsSuccessful() {
mailLogsStorage.logGood();
Assert.assertEquals(1, mailLogsStorage.getCountGood());
Assert.assertEquals(1, mailLogsStorage.getCountAll());
}
public void testEmailLogsFailed() {
mailLogsStorage.logBad();
Assert.assertEquals(1, mailLogsStorage.getCountBad());
}
23
// Good
public void testEmailLogsSuccessful() {
mailLogsStorage.logGood();
Assert.assertEquals(1, mailLogsStorage.getCountGood());
}
public void testEmailLogsFailed() {
mailLogsStorage.logBad();
Assert.assertEquals(1, mailLogsStorage.getCountBad());
}
@AfterMethod
public void cleanAfter() {
mailLogsStorage.cleanState();
}
Independent - test should runs with random order and in parallel.

// Bad
@BeforeTest
}
Assert.assertTrue(
service.sendMail(prepareGoodMail())
);
}
24
// Good
@BeforeTest
}
public void testEmailSendingSuccess() {
Assert.assertTrue(
service.sendMail(prepareGoodMail())
);
}
public void testEmailSendingFailed() {
Assert.assertFalse(
service.sendMail(prepareBadMail())
);
}
Checking all cases - tests for success case is not enough.

// Bad
@Before
public void before() {
service = new LogMailService();
service.setMailService(new MailService());
}
}
25
// Good
@Before
}
MailService mock = mock(MailService.class)
when(mock.sendMail(mail))
.thenReturn(true);
service.setMailService(mock)
times(1, mock.sendMail(mail));
}
Isolate - encapsulated logic should be covered with separated tests.

ISOLATION PHILOSOPHY
26
Mocking - creating objects that simulate
the behaviour of real objects to isolate
part of code for unit testing.

ISOLATION PHILOSOPHY28
Mocks - simulated objects that mimic the behavior of real objects in controlled
ways.
Partial mocks - object, created as shell for real one, when you need to stub
several methods of an object leaving the remainder free to respond to calls
normally.

@Before
}
@Test
MailService mock = mock(MailService.class)
when(mock.sendMail(mail))
.thenReturn(true);
service.setMailService(mock)
times(1, mock.sendMail(mail));
}
Mocks

@Test
public void testLogsRefresh() {
LogsStorage storageSpy = spy(logsStorage);
doReturn(true).when(storageSpy).flush();
storageSpy.refresh();
Assert.assertEquals(1, storageSpy.getCountAll());
times(1, storageSpy.flush());
}
Partial Mocks

Looks good… But

What if… we have private factory method?
Class MailService {
...
private Session createMailSession() {
...
}
}
32

Use dark power of
33
OR.. create a new class and move all private methods to this as
public. Use dependency injection and mocking. This can force you to
use an unwanted design. Private methods are not an option.

What if… we have calls to static method of framework?
Class MailService {
...
public Session sendMail() {
...
// Send message
Transport.send(message);
}
}
34

Use dark power of
35
OR... wrap all static method calls in a separate class and use
dependency injection to mock this object. This will create an extra
layer of unnecessary classes in your application. However, this can
of course be useful if you want to encapsulate the framework to be
able to replace it.

PowerMock for legacy code with antipatterns.
Mockito is enough for well constructed architecture.
36

Art of unit testing: How developer should care about code quality

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Art of unit testing: How developer should care about code quality

Similar to Art of unit testing: How developer should care about code quality (20)

Recently uploaded

Recently uploaded (20)

Art of unit testing: How developer should care about code quality