Introducci贸n

1

Qu茅 aprender谩s sobre Clean Architecture en Android

2

驴Qu茅 es clean architecture?

Repaso de Conceptos Generales

3

Principios SOLID

4

Repository Pattern

Presentaci贸n del proyecto

5

Presentaci贸n del proyecto: Rick and Morty

6

Uso de RxJava y RxAndroid en el proyecto

Capa de Presentaci贸n

7

Introducci贸n a la capa de presentaci贸n

8

Implementaci贸n de la capa de presentaci贸n

9

Soluci贸n del reto

Capa de Casos de Uso

10

Introducci贸n a la capa de casos de uso

11

Soluci贸n del reto: capa de casos de uso

Capa de Dominio

12

Introducci贸n a la capa de dominio

13

Implementaci贸n de la capa de dominio: mappers

14

Migraci贸n entidades de framework a dominio

15

Soluci贸n del reto: capa de dominio

Capa de Datos

16

Introducci贸n a la capa de datos

17

Implementaci贸n de la capa de datos: repositorio

18

Implementaci贸n de la capa de datos: fuente de datos

19

Soluci贸n del reto: capa de datos

Extras: Migraci贸n de Capa de Casos de Uso

20

Migraci贸n de la capa de casos de uso

Capa de Framework

21

Introducci贸n a la capa de framework

22

Implementaci贸n de Image Manager (Glide)

23

Implementaci贸n de Database Manager (Room)

24

Implementaci贸n de Request Manager (Retrofit)

Inyecci贸n de Dependencias

25

Introducci贸n a la inyecci贸n de dependencias

26

Implementaci贸n de Dagger (M贸dulos)

27

Implementaci贸n de Dagger (Componente)

28

Soluci贸n del reto: inyecci贸n de dependencias

Pruebas unitarias a nivel general

29

Implementaci贸n de pruebas unitarias (conceptos generales)

30

Pruebas unitarias en la capa de presentaci贸n

31

Pruebas unitarias en las capas de casos de uso y datos

Conclusiones

32

C贸mo seguir mejorando la arquitectura

A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Pruebas unitarias en la capa de presentaci贸n

30/32
Recursos

Aportes 2

Preguntas 0

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

Un poco de teor铆a para complementar

En Android existen test unitarios y test instrumentados

  • Test unitarios: se ejecutan en la MV de Java local y se ejecutan muy r谩pidamente (segundos o incluso milisegundos).
  • Test Instrumentados: se ejecutan en un dispositivo Android virtual o f铆sico, tardan en ejecutarse (varios segundos).

La idea de los tests unitarios, como dice el profe, es probar de forma individual y aislada algunas funciones.

<h3>@Rule</h3>

Nos permite tener reglas espec铆ficas para los tests. Por ejemplo:

@get:Rule
val rule: TestRule = InstantTaskExecutorRule()

Estamos anotando el getter de dicha regla. Esta regla en espec铆fico indica que se debe cambiar el executor a uno especial para entornos de pruebas.

<h3>@Mock</h3>

Nos permite crear mocks. Los mocks son un tipo de test doubles que registran las llamadas que se les hacen a dichos objetos.

<h3>@Before</h3>

Todas las funciones que tengan esta anotaci贸n se ejecutar谩n antes de cada uno de los tests. Se puede considerar hasta cierto punto como las 鈥減recondiciones鈥 de cada test.

<h3>@Test</h3>

Las funciones que sirvan como tests deben tener SIEMPRE esta anotaci贸n o no se ejecutar谩n como tests. Algo importante tambi茅n es el nombre. El nombre de la funci贸n es diferente al de las t铆picas funciones:

fun `should return a list of characters(){}`

Es otra forma de nombrar funciones. Esta nueva nomenclatura tiene 2 restricciones de uso

  • 脷NICAMENTE debe utilizarse en c贸digo de pruebas.
  • Solamente se pueden usar en pruebas unitarias. Ni Android ni en pruebas instrumentadas est谩n soportadas.
<h3>Estructura de los tests</h3>

Las pruebas de cualquier tipo normalmente siguen la convenci贸n Given-When-Then. O en espa帽ol: Dado/Dada/Dados/Dadas-Cuando-Entonces.

En el caso del test, estas partes est谩n de la siguiente manera:

    @Test
    fun `should return a list of characters`() {
	// Given: Dada una lista de caracteres y dado el caso de uso...
        val expectedResult = listOf(mockedCharacter)
        given(getAllCharactersUseCase(any())).willReturn(Single.just(expectedResult))

        characterListViewModel.events.observeForever(eventObserver)
	
	// When: Cuando el m茅todo onGetAllCharacters sea llamado
        characterListViewModel.onGetAllCharacters()
	
	// Then: Entonces se habr谩 emitido un evento de tipo ShowCharacterList con la lista previamente dada.
        verify(eventObserver).onChanged(
            Event(
                CharacterListViewModel.CharacterListNavigation.ShowCharacterList(
                    expectedResult
                )
            )
        )

        characterListViewModel.events.removeObserver(eventObserver)
    }

Nuestro objetivo es probar 煤nicamente la funci贸n onGetAllCharacters(), es por esto que hacemos un mock de getAllCharactersUseCase(), indic谩ndole que regrese Single.just(expectedResult) cuando sea llamado con cualquier argumento.

Finalmente, al profe se le olvid贸 a帽adir la siguiente l铆nea:
characterListViewModel.events.removeObserver(eventObserver)
Esta l铆nea quita el observer del LiveData.

Para mayor referencia a entender esta parte de Test, est谩 mucho mejor explicado en este curso:

Curso B谩sico de Testing en Java

Al menos para tener las bases.