A simple presentation that I did at work that goes over Unit Test, Mocking and TDD to improve development, it is explained from a Java perspective but can be helpful to apply TDD to other languages as well.

1. An Introduction To
Unit Testing & TDD

2. Content
1. Introduction
2. Unit Tests
3. Mocking
4. TDD

3. Introduction

4. Introduction
› Software development without testing.
› Not every part of the program should be
tested.
› Testing leads to higher software quality.

5. Testing Levels/Types
1. Acceptance Tests
2. System Tests
3. Integration Tests
4. Unit Tests
Acceptance
System
Unit
Integration
High Level
Low Level

6. Evaluate the
system's
compliance with
the business
requirements
After the system
testing is over, the
software is tested
by the client/user.
Acceptance Testing
Testing an
integrated system
to verify that it
meets specified
requirements.
Done by software
testing team.
Used to verify the
functionality,
performance, and
reliability of the
modules that are
integrated.
Either performed by
developers or testing
team, this depends on
the integrated layer
under test
The main aim is to
isolate each unit of
the system to
identify, analyze
and fix the defects.
Only a developer
should do it.
System Testing Integration Testing Unit Testing

7. Unit Tests

8. Unit Testing
› Aims to test the functionality of an isolated unit.
› Greatly helps in refactoring.
› Testing a function across two classes is
integration testing, not unit testing.
› Java has two major unit testing frameworks:
JUnit & TestNG.
› Code coverage: how many tests are executed
when running unit tests. Its frameworks are
JaCoCo, EclEMMA ( or EMMA)

9. Why Unit Testing?
› Quick changes to the
code.
› Documents code
design.
› Instant visual feedback
and diagnosis.
› Predict bugs and lower
development time.
› Verify code correctness.

10. Unit Testing Frameworks
JUnit
› Latest is JUnit5
› Most used test
framework, the official
Java test framework
TestNG
› Latest is TestNG 6
› Less used framework
but still favored by
many developers
1. TestNG had more features than JUnit4 but with JUnit 5 they
became almost equal to each other.
2. TestNG a little better reporting and support for parallelism
3. Maven supports using test units for both of them.
4. I will use JUnit in my example because it has more public
support but TestNG is an excellent framework nonetheless.

11. Simple JUnit Test Example
MyUnit.java
public class MyUnit {
public String
concatenate(String one,
String two){
return one + two;
}
}
MyTests.java
import org.junit.Test;
import static org.junit.Assert.*;
public class MyUnitTest {
@Test
public void testConcatenate() {
MyUnit myUnit = new MyUnit();
String result = myUnit.concatenate("one",
"two");
assertEquals("onetwo", result);
}
}

12. Basic JUnit Features & Annotations
@Test(expected, timeout): used to annotate a test.
@Before: annotates a function that runs before every test.
@BeforeClass: runs once before the whole class finishes execution.
@After: runs after every test.
@AfterClass: runs once after the whole class finishes execution.
@Ignore: a test function that is disabled.
Assert.*: multiple functions that are used to assert the correctness
of a test result (assertEquals, assertFalse, assertArraysEqual , ...etc.).
Test suite: it is a way to group test classes and run them together.
@Suite.SuiteClasses({tests .class array}): test classes of the suite.
@RunWith(Class<Runner>): marks the runner class which is a class
that implements Runner and used to run test classes with special
requirements( ex: PowerMockRunner.class & Suite.class )

13. Mocking

14. Mocking
› As we need to isolate a unit for testing,
the need for mocking has arisen.
› Before mocking, people had to create
fake classes to simulate the dependency.
› It is creating dependencies that simulate
the behavior of real dependencies.
› It also can verify function call.
› Mostly used for unit tests layer.

15. How Mocking Works
A proxy is made using reflection for
interfaces and bytecode rewrites for
mocking concrete classes.
As for mocking a static class, the classloader
is modified in compile-time to use a special
proxy class instead of the original class.

16. Java Mocking Frameworks
1. Mockito: Simple & clean API.Easy to learn.
2. PowerMock: Used for special cases, solves
Mockito disadvantages.
3. JMockit: Can mock every dependency but has a
steep learning curve.
4. EasyMock: Has many flexible options for
mocking, but has a small community.
I will be using Mockito + PowerMock combination
in my example as that give allow powerful
mocking that’s easy to learn.

17. Mockito Annotations & Features
@Mock/mock(): tells Mockito to mock objects, every function
will return an object or null/primitive type if not specified
@InjectMock: tells Mockito to inject its mocks into an object.
Mockito.verify(someFunction(),times(#)): verifies number of
calls of a specific function.
Mockito.when(someFunction()).[thenReturn()|thenAnswer()|the
nThrow()|thenCallRealMethod()]: stubs an action when a
mocked function is used.
Mockito.[doNothing()|doReturn()|doThrow()|doAnswer()].when
(mockObject).someFunction(): mocks a void function behaviour.
@Spy/Mockito.spy(new someObject): allows partial mocking so
only mocked functions return results but non-mocked functions
will work normally.
@Captor/Mockito.ArgumentCaptor: a special class to capture
the argument passed to a function when verifying it.

18. Mockito Example
@RunWith(MockitoJUnitRunner.class)
public class ItemServiceTest {
@Mock private ItemRepository itemRepository;
@InjectMocks private ItemService itemService;
@Test
public void getItemNameUpperCase() {
Item mockedItem = new Item("it1", "Item 1", "This is item 1", 2000, true);
when(itemRepository.findById("it1")).thenReturn(mockedItem);
String result = itemService.getItemNameUpperCase("it1");
verify(itemRepository, times(1)).findById("it1");
assertThat(result, "ITEM 1");
}
}

19. PowerMock
› It solves Mockito shortcomings.
› Used to mock constructors, static, final
and private methods.
› Mostly delegates the actual mocking to
the underlying mocking framework as
Mockito or EasyMock.

20. PowerMockito
› PowerMockito class is the integration
between Mockito and PowerMock.
› PowerMockito has most of Mockito
methods like mock(),spy(),when(),
doNothing() or thenReturn().
› It also has some other methods such as
mockStatic(), verifyStatic()

21. Mockito + PowerMock Example
@RunWith(PowerMockRunner.class)
@PrepareForTest({StaticService.class})
public class ItemServiceTest {
@Mock
private ItemRepository itemRepository;
@InjectMocks
private ItemService itemService;
@Before
public void setUp() throws Exception {MockitoAnnotations.initMocks(this);}
@Test
public void readItemDescriptionWithoutIOException() throws IOException {
String fileName = "DummyName";
PowerMockito.mockStatic(StaticService.class);
when(StaticService.readFile(fileName)).thenReturn("Dummy");
String value = itemService.readItemDescription(fileName);
PowerMockito.verifyStatic(times(1));
StaticService.readFile(fileName);
assertThat(value, "Dummy");
}
}

22. Test-Driven
Development (TDD)

23. Background
Test-Driven Development (TDD) originated
from eXtreme Programming (XP) paradigm
but continued into modern Agile paradigms.
A software development technique where
developers write a failing test that will
define the functionality before writing
actual code.

24. TDD Cycle and Rules
Red RefactorGreen
1. First, write an initially failing (RED) automated test case
that defines a new functionality.
2. Then produces the minimum amount of code to pass
(GREEN) test.
3. Finally refactors (REFACTOR) the new code to
acceptable standards.
4. Run tests again after refactoring if it fails re-do the cycle.
The cycles should be as short as possible.

25. TDD Flowchart
Add a test
Run The Test
Run the tests
Make a little change
[Pass]
[Fail]
[Fail]
[Pass]
Refactor
[Pass Refactoring]
[Development
Ends]
[Development
Continues]

26. › Ensures a clean working code that fulfills
requirements.
› Greatly decrease defects in the long run
with a slight increase in initial
development time.
› Increases productivity in the long run.
› Leads to high code coverage and more
unit tests as developers only write code
with preliminary tests.
Why TDD?

29. TDD Case Studies
Microsoft
40%-90%
pre-release defect
density decrease
with an increase of
15%-35% in initial
development.
IBM
40% fewer defects
with almost no
impact on team’s
productivity.
Ericsson
TDD increased
software quality
with an increase of
15% of initial
development.

30. Thanks!!