Art of unit testing: how to do it right

ART OF UNIT TESTING
how to do it right

About speaker
Few words about me:
◦ 10 years in software development
◦ Technical Lead at V.I.Tech
◦ Like culture
Hello!
I AM DMYTRO PATSERKOVSKYI

What we are talk about
◦ about developers thoughts;
◦ about code quality;
◦ about unit tests tips;
◦ about developers.

Developer, Level 1: thoughts
◦ code is good;
◦ code always works properly;
◦ if you think that you found a bug,
read above.

◦ as a usually, code works properly;
◦ code could have bugs;
◦ it is to expensive to write unit tests;
◦ we could test our code manually,
time to time;

? WHAT IS UNIT TEST?
@BeforeClass
public void testBeforeSuite() {
prepareMailService();
}
@Test
public void testEmailService() {
MailService service= generateMailService();
assertNotNull(service);
}
@Test
public void testSending() {
assertTrue(service.sendMail(subject, message));
}
Setup
Test Method
Assertion

◦ bugs happens;
◦ we should prevent bugs;
◦ it is cheaper to write unit tests;
◦ one unit test per class / method
should be enough.

? DO UNIT TESTS HAVE PRINCIPLES?
unit
simple
independent
complete
isolated
deterministic

? PROJECT ARCHITECTURE
Developer faced with component for sending emails.
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 - wrapper for work with emails
and logs.

? PRINCIPLES: UNIT & SIMPLE
// Bad
@Test
public void testEmailSending() {
assertNotNull(service);
MailBuilder builder= new MailBuilder();
Mail mail = new MailBuilder().
.newMail()
.addSubject("my mail")
.addRecipient(firstRecipient)
.addRecipient(secondRecipient)
.build();
assertNotNull(mail);
assertEquals(EXPECT, mail.getSubject());
...
assertTrue(service.sendMail(mail));
}
// Good
@BeforeTest
public void initialize() {
service= generateMailService();
}
@Test
assertTrue(
service.sendMail(prepareMail()));
}
each test should cover one piece of code

? PRINCIPLES: INDEPENDENT
test should runs in random order and in parallel
// Bad
@Test
public void testEmailLogsSuccessful() {
mlStorage.logGood();
assertEquals(1, mlStorage.getCountGood());
assertEquals(1, mlStorage.getCountAll());
}
@Test
public void testEmailLogsFailed() {
mlStorage.logBad();
assertEquals(1, mlStorage.getCountBad());
}
// Good
@Test
public void testEmailLogsSuccessful() {
mlStorage.logGood();
assertEquals(1, mlStorage.getCountGood());
}
@Test
public void testEmailLogsFailed() {
mlStorage.logBad();
assertEquals(1, mlStorage.getCountBad());
}
@AfterMethod
public void cleanAfter() {
mlStorage.cleanState();
}

? PRINCIPLES: COMPLETE
test should cover both: success and fail cases
// Bad
@BeforeTest
}
@Test
assertTrue(service
.sendMail(prepareGoodMail)));
}
// Good
@BeforeTest
}
@Test
public void testEmailSendingSuccess() {
assertTrue(service
.sendMail(prepareGoodMail()));
}
@Test
public void testEmailSendingFailed() {
assertFalse(service
.sendMail(prepareBadMail()));
}

? PRINCIPLES: ISOLATED
encapsulated logic should be covered with separated
tests
// Bad
@Before
public void before() {
service = new LogMailService();
service.setMailService(
new MailService());
}
@Test
public void testLogEmailService() {
assertTrue(
service.sendMail(mail));
}
// Good
@Mock
MailService mlMock;
@Before
service = new LogMailService();
}
@Test
public void testLogEmailService() {
when(mock.sendMail(mail))
.thenReturn(true);
service.setMailService(mlMock)
assertTrue(service.sendMail(mail));
times(1, mlMock.sendMail(mail));
}

? PRINCIPLES: DETERMINISTIC
Unit test behaviour should be reproducible
// Bad
@Before
service = new MailService();
}
@Test
service.sendMail(mail);
delay(1000);
assertEquals(1,
service.getSentCount());
}
// Good
@Mock
Transport transportMock;
@Before
service = new MailService();
service.setTransport(transportMock);
}
@Test
service.sendMail(mail);
assertEquals(1,
service.getSentCount());
}

Developer, Level 11 25: thoughts
◦ we have to use isolation frameworks;
◦ our code should be testable;
◦ unit tests improves code quality;
◦ unit tests catch bugs early;
◦ unit tests speed up debugging and
troubleshooting.

? HOW MANY UNITS I SHOULD WRITE TO SLEEP SAFETY?
one per class?
one per method?
90%?

? CODE COVERAGE
Line Coverage
Branch CoverageOverall Coverage
85% - min overall coverage

◦ we should know test coverage of
our code;
◦ we should use tools for calculating
coverage;
◦ high code coverage let us make
refactoring safety.

? WHAT ELSE UNITS COULD GIVE ME?
units as documentation;
units as design;

? UNITS AS DOCUMENTATION
Units are NOT a reference.
Units could (should) be used as helpful
documentation about:
◦ definition of class/interface contract;
◦ corner cases of functionality;
◦ list of behaviour.

? UNITS AS DESIGN
Writing the test first forces you to think
through your design and what it must
accomplish before you write the code.
TDD / BDD

◦ unit tests documents our code;
◦ TDD/BDD helps to look at design of
code from different point of view.

Know what you're
testing
A test written without a clear objective
in mind is easy to spot

Naming Convention
One of the first thing that you notice about
a failed test is its name

Do Repeat Yourself
Readability is very important in unit testing,
so it is acceptable to have duplicate code

Test Results, not
Implementation
Successful unit testing requires writing tests
that would only fail in case of an actual
error or requirement change

Art of unit testing: how to do it right

More Related Content

What's hot

Similar to Art of unit testing: how to do it right

Recently uploaded

Art of unit testing: how to do it right