Python Sudeste 2018
Além do MVC: Testando Unitariamente Apps Django
Bernardo Fontes
São Paulo / SP
30 de Março de 2018
DISCLAIMER
Esta é só a minha verdade
Testem
Testem confortavelmente
Arquitetura MVC
Problemas de MVC
Uma decisão estritamente arquitetural
O nível de abstração é alto
Esconde muitas outras camadas do framework
Não implica pensar o design da sua aplicação
Alta chance de misturar responsabilidades
Resultado: legados bebês
Minimizando os Problemas
Object Mentor (SOLID)
Single Responsibility Principle
Nunca deve exstir mais de uma razão para modificar algo em uma classe.
Single Responsibility Principle para testes
Nunca deve exstir mais de uma razão para TESTAR algo em um objeto.
Responsabilidades por Camada
Models: abstração para armazenar e consultar dados
Views: garantir fluxo HTTP de Request-Response para uma rota após executar o comportamento desejado
Templates: apresendar dados em algum formato (HTML em geral)
Nossa TODO List
class Todo(models.Model):
HIGH_PRIORITY, LOW_PRIORITY = 2, 1
PRIORITY_CHOICES = [(HIGH_PRIORITY, 'High'), (LOW_PRIORITY, 'Low')]
owner = models.ForeignKey(settings.AUTH_USER_MODEL)
content = models.CharField(max_length=100)
is_done = models.BooleanField(default=False)
priority = models.IntegerField(choices=PRIORITY_CHOICES, default=LOW_PRIORITY)
Melhore seu vocabulário
Domínio no Banco VS Domínio Desacoplado?
Nosso domínio viverá no model do Django (domínio no banco)
Responsabilidades por Camada
Models: abstração para armazenar e consultar dados com semântica de domínio
Testes de models precisam bater no banco
Alguém pensou em fixtures?
Model Mommy FTW!
pip install model_mommy
Model-mommy offers you a smart way to create fixtures for testing in Django. With a simple and powerful API you can create many objects with a single line of code.
Testando o Modelo de Dados
Defina uma API que represente seu domínio e encapsule seus dados
Teste como essa API manipula os dados
Toda a aplicação só operar sobre o banco através dessa API
from model_mommy import mommy
from django.tests import TestCase
from app.models import Todo
class TodoModelTests(TestCase):
def test_mark_as_high_priority(self):
todo = mommy.prepare(Todo, priority=Todo.LOW_PRIORITY)
todo.mark_as_high_priority()
asser Todo.HIGH_PRIORITY == todo.priority
def test_mark_as_low_priority(self):
todo = mommy.prepare(Todo, priority=Todo.HIGH_PRIORITY)
todo.mark_as_low_priority()
asser Todo.LOW_PRIORITY == todo.priority
Testando a Manipulação de Dados
Pare de pensar em query e pense em intenções
O que significa a consulta Todo.objects.filter(priority=1)?
Gere semântica de domínio através de Model Managers e QuerySets customizados
from model_mommy import mommy
from django.tests import TestCase
from app.models import Todo
class TodoModelManagerTests(TestCase):
def test_filter_high_priority(self):
expected = mommy.make(Todo, priority=Todo.HIGH_PRIORITY, _quantity=2)
mommy.make(Todo, priority=Todo.LOW_PRIORITY, _quantity=3)
qs = Todo.objects.high_priority()
self.assertQuerysetEqual(qs, expected)
def test_filter_incomplete(self):
expected = mommy.make(Todo, is_done=False, _quantity=3)
mommy.make(Todo, is_done=True, _quantity=2)
qs = Todo.objects.incomplete()
self.assertQuerysetEqual(qs, expected)
def test_filter_chained_incomplete_and_high_priority(self):
expected = mommy.make(
Todo, is_done=False, priority=Todo.HIGH_PRIORITY, _quantity=3
)
mommy.make(Todo, is_done=True, priority=Todo.HIGH_PRIORITY)
mommy.make(Todo, is_done=True, _quantity=2)
qs = Todo.objects.incomplete().high_priority()
self.assertQuerysetEqual(qs, expected)
Testando os Buracos Negros
Testar Views é chato!
Tenho que configurar o banco
Tenho que logar o usuário
Tenho que configurar permissões
Tenho que checar vários fluxos de sucesso
Tenho que lidar com os de falha
Se é chato/difícil de testar, isso pode ser um grande bad smell sobre seu código...
Responsabilidades por Camada
Views: garantir fluxo HTTP de Request-Response para uma rota após executar o comportamento desejado
fluxo HTTP
Request GET/POST...
404 para página não encontrada
200 para sucesso com conteúdo
302 para um redirect e por aí vai...
executar o comportamento desejado
Um exemplo antigo e meu
def index(request):
today = date().today()
hangovers = Hangover.objects.filter(day=today).count()
if request.method == 'GET':
context = RequestContext(request, {'hangovers': hangovers})
return render_to_response('index.html', context)
elif request.method == 'POST':
msg = 'Eu sou a {}ª pessoa #deressaca hoje! http://deressaca.net'.format(hangovers)
twitter_message = urllib.urlencode({'status': msg})
twitter_url = 'http://twitter.com/home?{}'.format(twitter_message)
if 'new_hangover' in request.POST:
Hangover.objects.create()
return HttpResponseRedirect(twitter_url)
else:
return HttpResponseRedirect(reverse('counter'))
Problemas para testar dessa view
- Requisições Get + Requisições Post
- Formatação da mensagem do Tweet
- Redirecionamento pro twitter com mensagem
- Criação de objeto Hangover
- Não criação de objeto Hangover
- Redirect para reverse de counter
Responsabilidades Reais da View
- Fluxo de Get Vs Fluxo de Post
Formatação da mensagem do TweetRedirecionamento pro twitter com mensagemCriação de objeto HangoverNão criação de objeto Hangover- Redirect para alguma url (reverse de counter ou do twitter)
Quem faz o resto então?
Habemus Use Cases
Use Cases
"The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case."
- Uncle Bob
Responsabilidades por Camada
Views: garantir fluxo HTTP de Request-Response para uma rota após executar um CASO DE USO
Como testar caso de uso? Mockando sua chamada!
Garantimos o funcionamento testando unitariamente o caso de uso
Mock
Simulam funcionamento de objetos
Respeitam API dos objetos
Viabilizam maneira de fazer asserções
Testes
class HangoverIndexTests(TestCase):
url = reverse_lazy('index')
def test_show_counter_on_context(self):
mommy.make(Hangover, day=date.today(), _quantity=4)
response = self.client.get(self.url)
self.assertEqual(4, response.context['hangovers'])
def test_uses_correct_template_on_get(self):
response = self.client.get(self.url)
self.assertTemplateUsed(response, 'index.html')
@patch.object(SendTwitterHangoverMessageUseCase, 'execute')
def test_redirects_to_use_case_url(self, mocked_execute):
mocked_execute.return_value = reverse('counter')
data = {'new_hangover': True}
response = self.client.post(self.url, data)
mocked_execute.assert_called_once_with(create_hangover=True)
self.assertRedirects(response, reverse('counter'))
Possível implementação
def index(request):
today = date.today()
hangovers = Hangover.objects.filter(day=today)
if request.method == 'GET':
context = RequestContext(request, {'hangovers': hangovers})
return render_to_response('index.html', context)
elif request.method == 'POST':
if 'new_hangover' not in request.POST:
return reverse('counter')
redirect_url = use_case.execute()
return HttpResponseRedirect(redirect_url)
Possível implementação
class SendTwitterHangoverMessageUseCase():
def execute(self):
today = date.today()
Hangover.objects.create()
hangovers = Hangover.objects.filter(day=today).count()
msg = 'Eu sou a {}ª pessoa #deressaca hoje! http://deressaca.net'.format(hangovers)
twitter_message = urllib.urlencode({'status': msg})
twitter_url = 'http://twitter.com/home?{}'.format(twitter_message)
return twitter_url
Definitivamente leia mais aqui:
Dicas extras para testar Views
Crie asserções customizadas para Views
Crie métodos auxiliares para gerência de usuários
Nunca mockar o comportamento padrão do Forms (bad smell)
Utlize mommy recipes =)
Testando a Área Cinza: Forms/Serializers
Responsabilidades
Validação, Sanitização e Formatação
Teste o que for dos Forms unitariamente! Lembre-se: testar pela view é chato
ModelForms nem sempre são uma boa idéia...
Garanta um output de dados desacoplado da API do Django
Forms também são bons canditados de asserções customizadas
class TodoListModelFormTests(TestCase):
def setUp(self):
self.data = {'content': 'content', 'owner': 42}
self.user = mommy.make(User, id=42)
def test_required_fields(self):
required_fields = ['content', 'owner']
form = TodoListForm({})
form.is_valid()
self.assertEqual(len(required_fields), len(form.errors))
for field in required_fields:
self.assertIn(field, form.errors)
def test_cleans_content_to_upper_case(self):
form = TodoListForm(self.data)
self.assertTrue(form.is_valid())
self.assertEqual('CONTENT', form.cleaned_data['content'])
def test_get_form_result_data(self):
form = TodoListForm(self.data)
self.assertTrue(form.is_valid())
data = form.get_result_data()
self.assertEqual('CONTENT', data['content'])
self.assertEqual(self.user, data['owner'])
def test_priority_choices_range(self):
priority_choices = [(1, 'High'), (2, 'Low')]
form = TodoListForm()
self.assertEqual(priority_choices, list(form.fields['priority'].choices))
Asserções Customizadas para Forms
def assertRequiredFields(self, required_fields, form_class, *args, **kwargs):
form = form_class(*args, **kwargs)
form.is_valid()
self.assertEqual(len(required_fields), len(form.errors))
for field in required_fields:
self.assertIn(field, form.errors)
def assertChoiceFieldOptions(self, expected_choices, form, field_name):
expected_choices = list(expected_choices)
self.assertEqual(expected_choices, list(form.fields[field_name].choices))
Responsabilidades dos Templates
Renderizar variáveis corretamente
Funcionamento de Template Filters
Funcionamento de Template Tags
Renderizar variáveis corretamente
TEMPLATE_STRING_IF_INVALID = 'XXXXX-INVALID_CONTEXT_VAR-XXXXXX'
def assertTemplateUsed(self, response, template_name):
super(TestCase, self).assertTemplateUsed(response, template_name)
self.assertNotIn(settings.TEMPLATE_STRING_IF_INVALID, response.content, self.__clean_template_output(response))
Template Tags e Filters
Validar o funcionamento
Validar que foi registrada
Template Library pode ser usada para ambos
def test_my_crazy_upper(self):
content = '{% load app_tags %}{{ "bernardo"|crazy_upper }}'
template = Template(content)
output = template.render({})
self.assertEqual("BeRnArDo", output)
Isso é só o começo...
Middlewares
Caching
Emails
Controle de permissões
APIs Rest e por aí vai
Resumindo
- Models, Managers e QuerySet com linguagem de domínio encapsulando detalhes de implentação e persistência
- Views só são responsáveis por fluxo HTTP e disparo de execução
- MVC define sua arquitetura, não seu design
- Use Cases podem ser seus amigos
- Teste Forms unitariamente para facilitar testes em camadas mais altas (views, por exemplo)
- Utilize a linguagem de Template do Django como amiga para testar Templates
