quarta-feira, 27 de abril de 2011

Como usar arquivos de teste durante testes unitários no VS 2010

Estamos testando a importação de arquivos de NFe's (Notas Fiscais Eletrônicas). Para construir testes que façam isto, precisei de um arquivo contendo uma NFe, e também dos XSD's pra validação do XML da NFe.

Quando você executa testes dentro do VS, ele cria um diretório chamado "TestResults" debaixo do diretório da sua solução, e pra cada execução de um teste, cria um subdiretório chamado "usuário_máquina AAAA-MM-DD hh_mm_ss", e dentro desse subdiretório cria um outro chamado Out, e é dentro desse Out que ficam os assemblies com o código do seu teste e o código a testar. Então qualquer arquivo que seja necessário durante os testes tem que ser copiados para este diretório.


Estrutura dos diretórios de execução dos testes, com os arquivos de testes já copiados para lá.

Achei algumas formas de fazer isso (Test > Edit Test Settings > blablabla.testsettings, opção Deployment; ou  [Propriedades do Arquivo] > Build Action = Content e Copy To Output Directory = Copy Always), mas a única coisa que funcionou mesmo foi o uso do atributo [DeploymentItem]:


Como usei em um método de teste, os arquivos só são copiados para o diretório de execução dos testes quando este método rodar. Mas pelo Help da MSDN, ele pode ser usado também em classes, o que (suponho) faz com que os arquivos sejam copiados para o diretório de execução para qualquer teste da classe.

Timeout em testes unitários no Visual Studio 2010

Nossos testes de unidade na aplicação Azure que estamos construíndo tem que limpar um monte de tabelas no Storage Emulator, que não é nenhuma Brastemp em termos de performance. Em algumas situçãoes a limpeza destas tabelas levava quase 6 segundos, e sendo 10 segundos o tempo máximo default para a execução de um teste, vários testes estavam gerando erro de timeout.

Uma possível solução é aumentar o tempo máximo de execução. No menu Test > Edit Test Settings > (sua configuração de testes.testsettings), selecione a opção Test Timeouts, e na opção Mark an individual test as failed if its execution time exceeds forneça o tempo que você deseja para timeout dos testes.

PS: Não faça como eu, que quis colocar 30 segundos e coloquei 30 minutos.
Só percebi quando estava escrevendo este post...

terça-feira, 19 de abril de 2011

Treinamento Azure: MSDN Code Sample for Cloud

Bem, este não é um "Treinamento", mas vale a pena colocar nas referências de treinamento para Azure: A MSDN disponibiliza uma biblioteca de código-fonte, e há uma seção para o Azure: http://code.msdn.microsoft.com/site/search?f%5B0%5D.Type=Platform&f%5B0%5D.Value=Cloud. Tem coisas muito interessante lá, e o legal é que dá pra ver como elas são implementadas. Particularmente vou dar uma checada no projeto CSAzureTableSt​oragePaging, que mostra como fazer paginação em cima de dados armazenados no ATS (em aplicações MVC). Teremos que fazer isto em breve...

segunda-feira, 18 de abril de 2011

Teste Unitário de Aplicações 64 bits no Visual Studio

Tivemos que ler um arquivo Excel na nossa aplicação Azure. Sendo uma aplicação Azure, ela necessariamente tem que ser 64 bits.

(…huuummmm… Mentira. Você pode ativar a execução de aplicações 32 bits em um IIS 64 bits de acordo com esse cara aqui ó)

Ok. Eu achei que uma aplicação no Azure tinha que ser 64 bits, então quando fomos ler um arquivo do Excel, instalamos o Provider OleDb de 64-bits para o Office 2010, que permite coisas muito legais, tais como usar um DataAdapter pra executar um comando tipo “SELECT * FROM $Planilha1” e jogar esses dados dentro de um DataSet.

O problema foi quando executei os testes unitários de acesso ao arquivo Excel. Os testes sempre falhavam com a exceção “The 'Provider=Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine”. Isto porque por default os testes unitários no Visual Studio 2010 rodam em um ambiente de 32 bits. Como o provider é de 64 bits, ele não é reconhecido pelo código dos testes.

Imaginei as coisas mais malucas pra fazer estes testes rodarem, como p.e. fazer uma aplicação console 64 bits que chamasse o componente a testar, disparar essa aplicação de um teste, e depois verificar os resultados. Perdi uma manhã inteira tentando executar essa aplicação console de forma sincrona, pois eu só podia checar os resultados depois que o processo acabasse.

(“PS”: Você sabia que é um parto em .NET fazer um código que dispara um processo e espera pelo fim da execução desse processo? Poizé, eu não.)

Mas no final das contas, o Visual Studio já tem suporte para execução de testes em 64 bits. Nas configurações de teste (menu Test > Edit Test Settings > [sua configuração de teste].testsettings), você pode ir em “Hosts” e na opção “Run tests in 32 or 64 bit process” selecionar “Run tests in 64 bit process on 64 bit machine”. Se seu Windows é de 64 bits, o ambiente no qual os testes são executados será também de 64 bits. Assim os testes usando o provider de 64 bits rodaram sem problemas.

image