1

TDD Injection Workshop

Test First CycleBy Orlando Garcia

Scrum Tropic Thunder Team

2

The business voice

We want you to implement a SMS sending feature for our cell phones

3

Nowadays tech requirements

Your code must be testable, self – documented, bug free, easy to read, clean…

4

Story 1: Sms sending

As a client, I want to send a SmsSo that I don´t have to call the contact

5

Scenario 1: Everything is OK

Given the Sms is already composedWhen client sends the SmsThen “SMS successfully sent” message is displayedAnd Sent folder contains the sent message

6

7

8

9

Test setup

• Declare and Create the object under test (out)– SmsSender sender; // object under test

• Create a setup method to get a new instance of out for every test scenario– @Before // JUnit annotation– @BeforeMethod // TestNG annotation

10

11

Write a Test

• First scenario– @Test sendDisplaysSmsSuccessfulySentWhenEverythingIsOk– @Test send_EverythingIsOk_SmsSuccessfulySent

• The most simple form of method under test– public void send(); // method under test

• Assertions. Look for “Then” scenario´s statements– State assertions– Behavior verifications– import static org.junit.Assert.assertEquals;

12

Compile the Test

• Dependencies declaration and construction– By hand

• new MockObjectX(); // fake object

– Using mock frameworks (Mockito, JMock, EasyMock, etc.)• ObjectToMock obj = mock(ObjectToMock.class);

13

Fail the Test

• Dependency Injection– By hand via setter method

• dependentObj.setDependency(dependencyMock);

– By hand via constructor method• new DependentObj(dependencyMock);

– Automatically with a DI framework• @Autowire; // spring like annotations

• @Inject; // guice like annotations

• Run

14

Pass the Test

• Implement object under test– It should satisfy test assertions and verifications– Improve assertions readability by using hamcrest

assertThat• import static org.junit.Assert.assertThat;• import static org.hamcrest.Matchers.*;

• Run

15

16

Refactor the object under test

• Is there a better way to implement it?• Any idea??? Look for design flaws (*):– Global State aka Singleton– Digging into Collaborators– Law of Demeter Violation– Global reference to time– Hard-coded new Operator– Lack of Dependency Injection

– (*) See Misko Hevery guide: Writing Testable Code

17

18

Digging into Collaborators

• Flaw: the object under test looks itself values to do its job– public void send() {

Sms sms = smsComposer.getSms();

• Solution: pass in the real needed object as a method parameter– public void send(Sms sms) {

Sms sms = smsComposer.getSms();

19

20

Scenario 2: Account Low on Credits

Given the SMS is already composedAnd the client’s account is low on creditsWhen client sends the SMSThen “Insufficient credits available” message is

displayedAnd the SMS is stored in Outbox folder

21

Scenario 3: Multiple contacts

Given the SMS is already composedAnd it is directed to 10 different contactsWhen client sends the SMSThen “SMS successfully sent” message is displayedAnd all 10 SMS are stored in Sent folder

22

Scenario 4: Any contact was selected

Given the SMS is already composed And there is any contact selectedWhen client sends the SMSThen “Please select a contact” message is

displayedAnd Contacts selector is displayed

23

Scenario 5: Message is empty

Given the SMS is already composedAnd the text message is emptyWhen client sends the SMSThen “Write a message before send” message is

displayedAnd the Message Editor is displayed

24

Scenario 6: Network Error

Given the SMS is already composedAnd the network service is unavaliableWhen client sends the SMSThen “Network error” message is displayedAnd the SMS is stored in Outbox folder

25