ELEGANT?? UNIT TESTING by Pablo Guardiola @Guardiola31337

TWITTER @Guardiola31337 WEBSITE pguardiola.com

4 rules of simple design 1. Runs all the Tests 2. Reveals all the intention 3. No duplication 4. Fewest number of classes or methods

On what are they all AGREED?

PASSES its tests!

Have you ever asked yourself, WHY? What MOTIVATES you to write tests?

Testing motivators Validate the System Code Coverage Enable Refactoring Document the Behaviour of the System Your Manager Told You To Test Driven Development Customer Acceptance Ping-Pong Pair Programming

Types of Tests STATE VERIFICATION BEHAVIOR VERIFICATION

HYBRID

Unit Test SOLITARY SOCIABLE 1. Never cross boundaries 2.The Class Under Test should be the only concrete class found in a test

FIRST FAST INDEPENDENT REPEATABLE SELF-VALIDATING TIMELY

Test Doubles DUMMY STUB SPY MOCK FAKE

Dummy public class DummyAuthorizer implements Authorizer {
 @Override
 public Boolean authorize(String username, String password) {
 return null;
 }
 }

Stub public class AcceptingAuthorizerStub implements Authorizer {
 @Override
 public Boolean authorize(String username, String password) {
 return true;
 }
 }

Spy public class AcceptingAuthorizerSpy implements Authorizer {
 public boolean authorizeWasCalled = false;
 
 public Boolean authorize(String username, String password) {
 authorizeWasCalled = true;
 return true;
 }
 }

Mock public class AcceptingAuthorizerVerificationMock implements Authorizer {
 public boolean authorizeWasCalled = false;
 
 public Boolean authorize(String username, String password) {
 authorizeWasCalled = true;
 return true;
 }
 
 public boolean verify() {
 return authorizeWasCalled;
 }
 }

Fake public class AcceptingAuthorizerFake implements Authorizer {
 public Boolean authorize(String username, String password) {
 return username.equals("Bob");
 }
 }

AAA ARRANGE ACT ASSERT

What about ANDROID?

ANDROID Unit Testing Java Module MVP CLEAN Architecture AS 1.1 + Android Gradle Plugin MVVM KOR Rosie?

DECOUPLED Architecture

Where do I START?

public class FooTest {
 
 @Test
 public void sampleTest() throws Exception {
 assertEquals(expected, actual);
 }
 } JUnit

Material Movies @Test
 public void obtainFiftyShadesOfGreyMovie() throws Exception {
 MediaDataSource inMemoryData = new InMemoryMovieSource();
 GetMoviesInMemoryUsecaseController popularMovies = new GetMoviesInMemoryUsecaseController(GetMoviesUsecase.TV_MOVIES, inMemoryData);
 
 popularMovies.execute();
 
 assertEquals("Fifty Shades of Grey", ((InMemoryMovieSource) popularMovies.obtainMediaData()).obtainInMemoryMovies().get(3).getTitle());
 }

Material Movies @Test
 public void checkIfPopularMoviesIsCalled() throws Exception {
 GetMoviesUsecase popularMovies = new GetMoviesUsecaseController(GetMoviesUsecase.TV_MOVIES);
 GetMoviesUsecase spy = Mockito.spy(popularMovies);
 
 spy.execute();
 
 verify(spy).getPopularMovies();
 }

How do I IMPROVE my tests? DAMP

One Assertion Per Test (State Verification) @Test public void shouldCreateVerboseTraceFromStringTrace() throws Exception {
 Trace trace = Trace.fromString(VERBOSE_TRACE);
 
 assertEquals(TraceLevel.VERBOSE, trace.getLevel());
 assertEquals(ANY_TRACE_DATE + " " + VERBOSE_TRACE_MESSAGE, trace.getMessage());
 }

ANNOYING to have to look at the STACKTRACE to know what’s FAILING Have NO INFORMATION about REMAINING TESTS

One Assertion Per Test (Behavior Verification) @Test public void shouldNotUpdateFilterIfPresenterIsNotInitialized() {
 presenter.updateFilter(ANY_FILTER);
 
 verify(lynx, never()).setConfig(any(LynxConfig.class));
 verify(lynx, never()).restart();
 }

1. If your test has an assertion, do not add any mock verifications 2. If your test verifies a mock, do not add any assertions 3. At most, 1 assertion per test 4. At most, 1 mock verification per test Rule of thumb

Expect Literals @Test
 public void testSaveAllNextLevel() throws Exception {
 doReturn(Boolean.TRUE).when(repository).hasNextLevel();
 
 assertEquals(elements.size(), repository.saveAll(elements).size());
 verify(nextLevel, times(1)).saveAll(anyCollection());
 }

READABILITY LITERALS will REFLECT the examples from the BUSINESS

Value Objects vs Expect Literals CONVERT VALUE OBJECT to a LITERAL

Inline Setup @Before
 public void setUp() throws Exception {
 initMocks(this);
 
 elements.add(mockedElement1);
 elements.add(mockedElement2);
 elements.add(mockedElement3);
 
 ids.add(EXPECTED_FIRST_ID);
 ids.add(EXPECTED_SECOND_ID);
 ids.add(EXPECTED_THIRD_ID);
 
 repository = new BaseFastRepositoryImpl(currentLevel, null);
 }

READABILITY Avoid CODE DUPLICATION? BUILDERS

Separating The Solitary From The Sociable 1. Can be slow and nondeterministic 2. Are more susceptible to cascading failures Sociable Unit Tests

Questionable Tests Testing Language Features or Standard Library Classes Testing Framework Features or Classes

Should we even bother writing Unit Tests? “The key is to test the areas that you are most worried about going wrong. That way you get the most benefit for your testing effort.” Martin Fowler, Refactoring

“Practice makes perfect.”

Thank you! @Guardiola31337 pguardiola.com

Extreme Programming Explained: Embrace Change, Kent Beck, AddisonWesley. Working Effectively with Unit Tests by Jay Fields Bibliography Mocks Aren’t Stubs (www.martinfowler.com/articles/mocksArentStubs.html) The Little Mocker (blog.8thlight.com/uncle-bob/2014/05/14/TheLittleMocker.html) https://github.com/saulmm/Material-Movies https://github.com/pedrovgs/Lynx https://github.com/Sefford/kor Clean Code: A handbook of Agile Software Craftsmanship, Robert C. Martin Software Craftsmanship by Sandro Mancuso