O Teste de Unidade é o objetivo principal do MVC Pattern?

14

Recentemente, em uma entrevista, uma das perguntas foi 'Por que usamos o MVC?' Acabei de responder que está muito mais próximo de como estão muitos sistemas do mundo real! Expliquei os benefícios que ele tem em relação à manutenção, escalabilidade etc. Mas eles não ficaram convencidos e finalmente me disseram que o MVC é usado principalmente porque 'permite testes de unidade fáceis'.

Embora eu saiba que o ponto é válido, eu ainda duvido que esse seja o principal motivo, porque (i) mesmo que eu decida não escrever Unit Testcases, o MVC é uma escolha provável (ii) Muitos sistemas GUI em que existem Unit Testcases siga o MVC.

Portanto, a pergunta é 'O teste de unidade é o objetivo principal do MVC Pattern?'

EDIT: Suponho que eles estejam mencionando a facilidade do Test Driven Development / escrevendo NUnit Testcases. Isso ocorre porque podemos escrever casos de teste para o modelo (desde que a exibição esteja refletindo exatamente as alterações de estado do modelo) - corrija-me se estiver errado.

mvc

— WinW
fonte

11

Você não passou na entrevista, não é? Se não, você tem sorte. Não vou ingressar em uma empresa que tenha uma mentalidade muito errada desde o início. :) Teste de unidade Definitivamente não é o objetivo principal. Isso pode ajudar no teste de unidade porque a preocupação se separou, mas definitivamente não é o objetivo principal.

— Rudy

4

Lembre-se de que a entrevista funciona nos dois sentidos. Você está sondando-os tanto quanto eles estão testando você. Você acabou de receber uma bandeira vermelha: não entre nesta empresa. Eles não têm idéia, mas ainda pior, pensam que não sabem disso, então não há esperança de melhoria. Se você optar por entrar na empresa, enfrentará muitas situações kafkianas.

— deadalnix

@ Rudy Não, eu não passei: P, era o Dev Center de um banco de investimento líder. Também os caras pareciam bons e muito autênticos com outras perguntas, e é por isso que fiquei confuso com isso.

— WinW 21/07

@deadalnix, Sim, é verdade ... sinta o mesmo depois de ver as respostas aqui. Mas eu não tinha tanta certeza antes de postar aqui.

— WinW 21/07

Eu concordo totalmente com o deadalnix. Não vá para esta empresa.

— Rudy

33

O objetivo principal seria "separação de preocupações", pois o modelo, a visualização e o controlador têm responsabilidades distintas.

O autor do documento original da Xerox PARC afirma que:

O objetivo essencial do MVC é preencher a lacuna entre o modelo mental do usuário humano e o modelo digital existente no computador.

Se o teste de unidade fosse o objetivo principal, seria possível visualizar facilmente as visualizações de teste de unidade. Uma análise do panorama dos projetos / estruturas de teste de unidade revelaria que isso é totalmente contrário à afirmação feita. Um seria tipicamente usando testes funcionais e de integração para testar a exibição.

— Vineet Reynolds
fonte

2

Eu diria que os objetivos principais são habilitar a Metáfora de Manipulação Direta (que é basicamente o que a citação diz) e o Empoderamento do Usuário (foi originalmente previsto que apenas os Modelos seriam escritos por programadores, as Exibições e Controladores seriam escritos pelos usuários finais).

— Jörg W Mittag

14

Na minha opinião, a resposta é um firme "não". Talvez esse tenha sido o principal benefício observado nessa organização específica, mas eu não o chamaria de 'objetivo principal'.

Eu acho que não seria tão difícil implementar o MVC de alguma forma, isso é extremamente difícil de testar na unidade (caramba - o jeito que eu o fiz pela primeira vez foi dificilmente testável).

Por outro lado, pode-se dizer que praticamente qualquer padrão (excluindo coisas como Singleton) facilita o teste de unidade, pois geralmente promove o desacoplamento - mas esse é o seu 'objetivo principal'? Dificilmente.

— Mchl
fonte

12

O MVC (assim como a maioria dos padrões de design conhecidos) já existia antes de o teste de unidade se tornar conhecido. O livro do GoF foi publicado em 1994 - e eles estavam apenas documentando os padrões que estão em uso há anos (se não décadas) antes. (E não há menção a testes de unidade nele.) Sobre o teste de unidade, não consigo localizar um horário exato em que se tornou "público" - eu pessoalmente li sobre isso em artigos relacionados à Extreme Programming e ao primeiro livro do XP saiu em 1999.

Então, obviamente, o teste de unidade não poderia ser o objetivo principal de inventar / documentar padrões - embora seja justo dizer que os padrões, quando aplicados bem, facilitam bastante o teste de unidade.

— Péter Török
fonte

A referência da linha do tempo é uma boa referência mencionada.

— WinW 21/07

Parece haver um pequeno problema com a data. heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html diz que "o MVC foi concebido em 1978 como a solução de design para um problema específico". Não se preocupe ... Ainda assim, seu argumento é válido - o MVC estava lá muito antes da origem do teste de unidade.

— WinW 21/07

O teste de unidade existe desde pelo menos os anos 80. Eu estava começando minha carreira naquela época e tínhamos testes de unidade em alguns dos projetos em que trabalhei (e não parecia uma idéia nova). Nós simplesmente não tínhamos as estruturas pré-criadas que temos agora.

— GreenMatt

2

@ GreenMatt, eu sei que o teste de unidade não foi inventado por Kent Beck, apenas reutilizado :-) Mas o AFAIK era relativamente desconhecido antes do XP e do Agile começarem a propagá-lo amplamente.

— Péter Török

@ Péter Török: Lembro-me de 1) escrever meu próprio código simples para testar funções individuais até a faculdade (início da metade dos anos 80 para mim) e que recebi a idéia de outra pessoa; 2) ver representações e ler artigos sobre o modelo em cascata nos anos 80 ou 90 com uma fase chamada "Codificação e Teste de Unidade" (vs. apenas "Codificação"). (Desculpe, não me lembro onde, por isso não posso fornecer citações.) Assim, o teste de unidade existe e evolui há um bom tempo.

— precisa saber é o seguinte

2

Acho que não, a facilidade do teste de unidade é um dos benefícios, mas faz parte de uma coleção de benefícios ao usar o MVC, juntamente com os motivos que você lista. Dizer que existe um único motivo principal para usar o MVC é um erro. Parece que a empresa em questão escolhe o MVC para facilitar o teste de unidade; portanto, eles acham que esse é o principal motivo. Pessoalmente, minhas razões para usar o MVC são sua simplicidade em comparação aos formulários da Web, o que facilita o design e a manutenção, mas cada indivíduo / empresa terá seus próprios motivos para usar qualquer tecnologia.

— Robert Anton Reese
fonte

0

No mundo do ASP.NET MVC, muitas melhorias no ASP.NET foram incluídas na própria estrutura. O principal objetivo desse padrão de design é isolar a lógica de negócios da interface do usuário, a fim de focar em melhor manutenção, melhor testabilidade e uma estrutura mais limpa para o aplicativo.

O ASP.NET MVC possui certos recursos que o tornam a melhor opção para escolher se você precisa de um ou mais dos seguintes itens:

• Um alto nível de controle sobre o HTML gerado : Ao contrário dos Web Forms, as exibições no ASP.NET MVC processam o HTML exatamente como você deseja. Recentemente, os Web Forms foram aprimorados nessa área, mas ainda não possuem o nível de controle que o MVC possui.

• Teste de unidade mais fácil : com o ASP.NET MVC, é muito fácil seguir padrões de teste, como o TDD (Test-driven Development). Devido ao complexo ciclo de vida do evento nos Web Forms, além de uma estrutura baseada em controle, o TDD é muito mais fácil com o MVC.

• Separação de preocupações : refere-se a ter todos os aspectos do sistema claramente separados um do outro. Por causa do padrão implementado, um aplicativo MVC é dividido em partes discretas e fracamente ligadas (modelo, visualizações e controladores), o que facilita a manutenção.

Alguns dos outros benefícios são:

• O próprio padrão MVC facilita o gerenciamento da complexidade, separando claramente a funcionalidade do aplicativo em três partes principais: o modelo, a visualização e o controlador.

• Os aplicativos Web ASP.NET MVC não usam o estado de exibição ou os formulários baseados em servidor. Isso torna a estrutura MVC ideal para desenvolvedores que desejam controle total sobre o comportamento de um aplicativo. O estado de exibição pode se tornar muito grande, o que é um problema para dispositivos como smartphones executando redes lentas (transmitir todas essas informações pode ser muito lento). Em uma página de formulários da Web, você pode ter apenas um por página. Essa é uma restrição bastante importante. No MVC, não existe essa restrição - ou seja, você pode ter quantos elementos quiser.

• O ASP.NET MVC fornece melhor suporte para o TDD (Test-driven Development).

• O ASP.NET MVC funciona bem para aplicativos da web suportados por grandes equipes de desenvolvedores e para designers da web que precisam de um alto grau de controle sobre o HTML. Processamento de solicitação do ASP.NET MVC

— Arvind Kumar
fonte