JDD 2016 - Sebastian Malaca - You Dont Need Unit Tests

You don’t need unit tests!
Sebastian Malaca

Who am I?
Fanatic of the OOP and the Code’s Quality
Blogger
Speaker
Trainer and consultant
Software Developer at Luxoft
@SebastianMalaca
letstalkaboutjava.blogspot.com

Unit tests - what we will gain?
Documentation
Easy to Refactor
Easy to Modify
Testable Code = good Design
Safety

Documentation? Or implementation?
void apply(ClassCode code) {
if (code.isComplex() || code.isUnreadable()) {
refactor(code);
}
}
@Test
public void shouldRefactorCodeWhenIsUnreadable() { ... }
@Test
public void shouldRefactorCodeWhenIsComplex() { ... }
@Test
public void shouldNotRefactorCodeWhenIsNotComplexNorUnreadable() { ... }

if (code.isComplexOrUnreadable()) {
refactor(code);
}
}
@Test
public void shouldRefactorCodeWhenIsComplexOrUnreadable() { ... }
@Test
public void shouldNotRefactorCodeWhenIsNotComplexNorUnreadable() { ... }

if (code.isComplexOrUnreadable() && code.isEditable()) {
refactor(code);
}
}
@Test
public void shouldRefactorCodeWhenIsComplexOrUnreadableAndEditable()
{ ... }
@Test
public void shouldNotRefactorCodeWhenIsComplexOrUnreadableAndNotEditable()
{ ... }
@Test
public void shouldNotRefactorCodeWhenIsNotComplexNorUnreadableAndEditable ()
{ ... }
@Test
public void shouldNotRefactorCodeWhenIsNotComplexNorUnreadableAndNotEditable ()
{ ... }

What you have to understand to understand tests?
refactor(code);
}
}
complex unreadable
yes yes
yes no
no yes
no no

@Test
public void
shouldRefactorCodeWhenIsComplexAndUnreadable() {
ClassCode code = mock(ClassCode.class);
given(code.isComplex()).willReturn(true);
given(code.isUnreadable()).willReturn(true);
processor.apply(code);
// assertion
}
refactor(code);
}
}
complex unreadable
yes yes
yes no
no yes
no no

@Test
public void shouldRefactorCodeWhenIsComplex() {
given(code.isComplex()).willReturn(true);
// assertion
}
refactor(code);
}
}
complex unreadable
yes yes
yes no
no yes
no no

@Test
public void shouldRefactorCodeWhenIsUnreadable() {
given(code.isUnreadable()).willReturn(true);
// assertion
}
refactor(code);
}
}
complex unreadable
yes yes
yes no
no yes
no no

@Test
public void
shouldNotRefactorCodeWhenIsNotComplexNorUnreadable() {
// assertion
}
refactor(code);
}
}
complex unreadable
yes yes
yes no
no yes
no no

Too much is too much…
void refactor(ClassCode code, Developer developer) {
if (gitRepository.testsExistsFor(code.getClassName())) {
Roles roles = developer.getRoles();
if (code.mayBeModifiedBy(roles)) {
GitLogin login = developer.getGitLogin();
startRefactoringOf(code, login);
}
}
}

}
}
}
@Test
public void shouldNotRefactorWhenTestsDoesNotExist()
{ ... }
@Test
public void shouldNotRefactorWhenTestsExistsAndDeveloperCannotModifyCode()
{ ... }
@Test
public void shouldRefactorWhenTestsExistsAndDeveloperCanModifyCode()
{ ... }

}
}
}
private static final GitLogin SOME_GIT_LOGIN = mock(GitLogin.class);
private static final Roles SOME_ROLES = mock(Roles.class);
private static final String SOME_CLASS_NAME = "SomeClass";
@Mock private ClassCode code;
@Mock private Developer developer;
@Before
public void init() {
given(code.getClassName()).willReturn(SOME_CLASS_NAME);
given(developer.getRoles()).willReturn(SOME_ROLES);
given(developer.getGitLogin()).willReturn(SOME_GIT_LOGIN);
}

Do you really feel safe?
public class ProcessingHandler {
private final List<Processor> processors;
public ProcessingHandler(List<Processor> processors) {
this.processors = processors;
}
public Output process(Input input) {
for (Processor processor : processors) {
if (processor.isApplicableFor(input)) {
return processor.process(input);
}
}
return DEFAULT_OUTPUT;
}
}

}
}
}
@Test
public void shouldReturnDefaultOutputWhenApplicableProcessorNotFound()
{ ... }
@Test
public void shouldReturnOutputCreatedByApplicableProcessor()
{ ... }

public class ProcessingHandler {
private final List<Processor> processors;
public ProcessingHandler(List<Processor> processors) {
this.processors = processors;
}
// some code
}
<bean id="processingHandler"
class="com.smalaca.processor.ProcessingHandler">
<constructor-arg name="processors">
<bean class="com.smalaca.processor.ConcreteProcessor1"/>
</constructor-arg>
</bean>

Assumptions may change…
public class ConcreteProcessor1 extends Processor {
return anOututFor(input);
}
// some code
}

if (isEverythingOk(input)) {
}
return null;
}
// some code
}
}
// some code
}

}
}
}
}
return null;
}
// some code
}

}
}
}
return null;
}
// some code
}

@Test
public void shouldReturnDefaultOutputWhenApplicableProcessorNotFound() {
given(processor.isApplicableFor(SOME_INPUT)).willReturn(false);
// some code
}
@Test
public void shouldReturnOutputCreatedByApplicableProcessor() {
given(processor.isApplicableFor(SOME_INPUT)).willReturn(true);
given(processor.process(SOME_INPUT)).willReturn(SOME_OUTPUT);
// some code
}
}
}

Implementation or funcationality?
Why, not How
Modifiers and accesors?

TDD – be lazy in a good way
refactor(code);
}
}

TDD – be lazy in a good way
@Test
public void shouldRefactorCodeWhenCodeShouldBeImproved() {
given(code.shouldBeImproved()).willReturn(true);
// test
}
@Test
public void shouldNotRefactorCodeWhenCodeDoesNotHaveToBeImproved() {
given(code.shouldBeImproved()).willReturn(false);
// test
}
refactor(code);
}
}

Component Tests!
Normal flow
Most critical scenarios
Public API and package private
Refactoring/Redesign

Boundaries
Boundary Object
Integration/Component Tests
What to mock and what not to?

Don’t Mock everything!
Less assumptions
Creation is light
Input
Change = fast feedback
You are the owner

Do you really need unit tests?

JDD 2016 - Sebastian Malaca - You Dont Need Unit Tests

JDD 2016 - Sebastian Malaca - You Dont Need Unit Tests

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à JDD 2016 - Sebastian Malaca - You Dont Need Unit Tests

Similaire à JDD 2016 - Sebastian Malaca - You Dont Need Unit Tests (20)

Dernier

Dernier (20)

JDD 2016 - Sebastian Malaca - You Dont Need Unit Tests