arquivos Mensais: Janeiro 2014

Coitado do cache em JavaScript

[TL;DR versão: utilizamos cookies para armazenar os resultados de chamadas assíncronas; processar os resultados das últimas chamadas assíncronas imediatamente e em seguida, validá-los após o carregamento da página.]

Tenho trabalhado no site de intranet do SharePoint para um cliente que apresenta, entre outras coisas, uma navegação secundária estilizada, cujas opções de menu são gerenciadas através de uma lista personalizada velha regular.  A idéia é que o cliente obtém controle menu do "seu" site sem afetar ou ser afetado pela navegação global, por isso.

(Há algo de incrivelmente subversiva sobre a adição de um CEWP que aponta para um arquivo HTML que carrega alguns CSS e JS fundamentalmente alterar quase tudo sobre o comportamento de um site... mas isso é para outro post)

O código para esta bem simples:

O local dolorido, aqui é que toda vez que alguém bate uma das páginas do site, navegador da web do usuário que está tentando para obter os itens da lista.  Uma vez que o colaborador é completo e teste provou coisas para ser estável e completa, Essa chamada não é necessário mais do que 99% o tempo desde o menu raramente muda.  Também tem um estranho efeito de interface do usuário que é comum este admirável mundo novo de hiper-ajaxy web sites – processa a página e só então é que o menu render.  É nervosa e distraindo na minha opinião.  E nervoso. Assim, armazenamento em cache. 

Eu modifiquei a lógica desta forma:

  • Procure um cookie no navegador que contém o menu como última li-
    • Se encontrou, torná-lo imediatamente.  Não espere terminar o carregamento da página.  (Você precisa ter certeza de que seu HTML é estrategicamente colocado aqui, Mas não é difícil de fazer).
  • Esperar a página terminar de carregar e fazer async chamada para carregar itens de menu de uma lista usando o resto ou Lists. asmx ou qualquer outro
  • Comparar o que eu tenho contra o cookie
    • Se combina com, PARAR
    • Caso contrário, usando jQuery, popular dinamicamente um bando se <Li>está em um <UL>
  • Usar CSS para fazer toda a formatação
  • Lucro!

Alguns de vocês vão dizer, "Ei! Não há verdadeiro cache aqui desde que você está lendo o menu Enfim cada vez que.”  E você está certo-eu não vou dar o servidor qualquer tipo de pausa.  Mas porque a chamada é assíncrona e acontece após a página inicial carga HTML totalmente processa, "parece" mais ágil para o usuário.  O menu processa muito tanto quanto desenha a página.  Se o menu acontece para a mudança, o usuário é submetido a uma re-desenhar nervoso do menu, Mas só uma vez.

Existem algumas maneiras de tornar mais eficaz esta cache e ajudar o servidor ao mesmo tempo:

  • Colocar em uma regra que o cache de"cookie" é válido por um período mínimo de 24 horas ou algum outro período de tempo. Enquanto não há nenhum cookie expirado, Use o instantâneo de menu do cookie e nunca bateu o servidor.

Bem... isso é tudo o que vêm à mente agora :). 

Se alguém tiver alguma idéia inteligente aqui eu adoraria conhecê-los.

E por último – esta técnica pode ser usada para outras coisas.  Página do cliente, este tem uma série de coisas orientado a dados em várias páginas, muitos deles relativamente raramente mudando (como uma vez por semana ou uma vez por mês).  Se você destinar a áreas específicas de funcionalidade, Você pode dar uma interface de usuário mais responsiva puxando o conteúdo da loja do cookie local e tornando-se imediatamente.  Parece mais rápido para o usuário, mesmo se você não está salvando o servidor qualquer ciclos.  Você pode Salve os ciclos de servidor por decidir em algumas condições e gatilhos para invalidar esta cache local de cookie.  Isso é tudo situacional e artsy coisas e realmente a coisa mais divertida :). 

</fim>

undefinedSubscreva ao meu blog.

Siga-me no Twitter em http://www.twitter.com/pagalvin

Como: Configurar o teste unitário e cobertura de teste com QUnit.js e Blanket.js para um escritório 365 App do SharePoint

Intro

Eu estive explorando testes de unidade e teste de cobertura para JavaScript como eu trabalho em um novo aplicativo do SharePoint para SharePoint online no escritório 365 Suite.  Os caminhos de pesquisa óbvio levaram-me a Qunit.js e logo depois que, Para Blanket.js.

QUnit deixe-me criar testes de unidade e agrupá-los em módulos.  Um módulo é apenas uma maneira simples de organizar testes relacionados. (Não tenho certeza se que vou usá-lo como pretendido, Mas funcionou para mim até agora com o pequeno conjunto de testes que definiu até agora).

Blanket.js integra com Qunit e ele vai me mostrar as linhas reais de JavaScript que foram – e mais importante – não foram realmente executadas no decurso da execução dos testes.  Esta é a "cobertura" – linhas que executado são cobertas pelo teste, enquanto outros não são.

Entre a criação de casos de teste boas e visualização de cobertura, Podemos reduzir o risco de que nosso código escondido defeitos.  Bons tempos.

Qunit

Supondo que você tenha seu Visual Studio projeto configurado, Comece baixando o pacote de instalação JavaScript http://qunitjs.com.  Adicione o JavaScript e CSS correspondente à sua solução.  Mina parece com isso:

image

Figura 1

Como você pode ver, Eu estava usando 1.13.0 na época, eu escrevi este post de blog. Não se esqueça de baixar e adicionar o arquivo CSS.

Que saia do caminho, próximo passo é criar algum tipo de equipamento de teste e referenciar os bits Qunit.  Estou testando um monte de funções em um arquivo de script chamado "QuizUtil.js", então eu criei uma página HTML chamada "QuizUtil_test.html", como mostrado:

image Figura 2

Aqui está o código:

<!DOCTYPE HTML>
<HTML xmlns= "http://www.w3.org/TR/1998/REC-xml-19980210 1999/xhtml">
<cabeça>
    <título>Teste de QuizUtil com Qunit</título>
    <link rel= "stylesheet" href="../CSS/qunit-1.13.0.css" />
    <script tipo= text/javascript"" src="QuizUtil.js" dados-capa></script>
    <script type ="text/javascript" src ="qunit-1.13.0.js"></script>
    <script type ="text/javascript" src ="blanket.min.js"></script>

    <script>
        módulo("getIDFromLookup");
        teste("QuizUtil getIDFromLookupField", função () {
            var goodValue = "1;#Paul Galvin";

            igual(getIDFromLookupField(goodValue) + 1, 2), "ID do [" + goodValue + "] + 1 deve ser 2";
            igual(getIDFromLookupField(indefinido), indefinido, "O argumento de entrada indefinido deve retornar o resultado indefinido.");
            igual(getIDFromLookupField(""), indefinido, "O argumento de entrada vazio deve retornar um valor indefinido.");
            igual(getIDFromLookupField("gobbledigood3-thq;ada dkvn;skfja sdjfbvubvqrubqer0873407t534piutheqw;vn"), indefinido,"Deve sempre retornar um conversível de resultado para um número inteiro");
            igual(getIDFromLookupField("2;#outra pessoa"), "2", "Verificação [2;#outra pessoa].");
            igual(getIDFromLookupField("9834524;#valor longo"), "9834524", "Teste de grande valor.");
            notEqual(getIDFromLookupField("5;#qualquer um", 6), 6, "Testar um notEqual (5 Não é igual a 6 para esta amostra: [5;#qualquer um]");

        });

        módulo("htmlEscape");
        teste("QuizUtil htmlEscape()", função () {
            igual(htmlEscape("<"), "&lt;", "Escapando um menos que o operador ('<')");
            igual(htmlEscape("<classe div =  "someclass">Algum texto</div>"), "&lt;classe div =&quot;SomeClass&quot;&gt;Algum texto&lt;/div&gt;", "Sequência de teste mais complexa.");
        });

        módulo("getDateAsCaml");
        teste("QuizUtil getDateAsCaml()", função () {
            igual(getDateAsCaml(Novo Data("31/12/2013")), "2013-12-31T:00:00:00", "Teste codificada data: [12/31/2013]");
            igual(getDateAsCaml(Novo Data("01/05/2014")), "2014-01-05T:00:00:00", "Teste codificada data: [01/05/2014]");
            igual(getDateAsCaml(Novo Data("01/31/2014")), "2014-01-31T:00:00:00", "Teste codificada data: [01/31/2014]");
            igual(getTodayAsCaml(), getDateAsCaml(Novo Data()), "getTodayAsCaml() deve ser igual getDateAsCaml(nova data())");
            igual(getDateAsCaml("valor absurdo"), indefinido, "Tente obter a data de um valor absurdo.");
            igual(getDateAsCaml(indefinido), indefinido, "Tente obter a data da [indefinido] Data.");
        });

        módulo("getParameterByName");
        teste("QuizUtil getParameterByName (da cadeia de caracteres de consulta)", função () {
            igual(getParameterByName(indefinido), indefinido, "Tentar obter parâmetro indefinido deve retornar indefinido.");
            igual(getParameterByName("não existe"), indefinido, "Tentar obter o valor do parâmetro, quando sabemos que o parâmetro não existe.");

        });

        módulo("Cookies");
        teste("QuizUtil várias funções do cookie.", função () {
            igual(setCookie("teste", "1", -1), getCookieValue("teste"), "Obter um cookie eu definir deve funcionar.");
            igual(setCookie("anycookie", "1", -1), verdadeiro, "Definir uma cozedura válido deve retornar 'verdadeiro'.");
            igual(setCookie("nome do cookie louco !@#$%"%\^&*(()?/><.,", "1", -1), verdadeiro, "Definir um nome de cookie ruim deve retornar 'falso'.");
            igual(setCookie(indefinido, "1", -1), indefinido, "Passando indefinido como o nome do cookie.");
            igual(getCookieValue("não existe"), "", "Cookie não existe teste.");
        });

    </script>
</cabeça>
<corpo>
    <div ID= "qunit"></div>
    <div ID= "qunit-dispositivo elétrico"></div>

</corpo>
</HTML>

Existem várias coisas a acontecer aqui:

  1. Referenciando o meu código (QuizUtil.js)
  2. Referência Qunity.js
  3. Definição de alguns módulos (getIDFromLookup, Cookies, e outros)
  4. Colocando um <div> cuja ID é "qunit".

Em seguida, Só parar nesta página e você obter algo como isto:

image

Figura 3

Se você olhar no topo, Você tem algumas opções, dois dos quais são interessantes:

  • Ocultar passada testes: Bem óbvio.  Pode ajudar o seu olho vê apenas as áreas de problema e não um monte de desordem.
  • Módulo: (Deixe cair para baixo): Isso filtrará os testes até apenas os grupos de testes que você quer.

Quanto os testes se-alguns comentários:

  • Escusado será dizer que você precisa para escrever seu código de tal forma que é testável em primeiro lugar.  Usando a ferramenta pode ajudar a impor essa disciplina. Por exemplo, Eu tinha uma função chamada "getTodayAsCaml()”.  Isso não é muito testável, uma vez que não leva nenhum argumento de entrada e para testá-lo para a igualdade, precisamos atualizar constantemente o código de teste para refletir a data atual.  Eu refatorado isso adicionando um parâmetro de entrada de dados, em seguida, passando a data atual, quando eu quero a data atual no formato do CAML.
  • O quadro de Qunit documentos seus próprios testes e parece bastante robusto.  Ele pode fazer coisas simples, como teste de igualdade e também tem suporte para chamadas de estilo ajax ("real" ou fictícios usando seu favorito mocker).
  • Passando pelo processo também força você a pensar em casos extremos – o que acontece com o "indefinido" ou null é passado para uma função.  Torna absolutamente simples testar esses cenários para fora.  Coisas boas.

Cobertura com Blanket.js

Blanket.js complementa Qunit seguindo as linhas reais de código que executar durante o curso da executando os testes.  Então mesmo que é um aplicativo totalmente separado integra direito em Qunit, Ele joga muito bem – parece que é um app sem emenda.

Isto é blanket.js em ação:

image Figura 4

image

Figura 5

(Você realmente tem que clicar sobre a opção "Ativar a cobertura" no topo [Ver figura 3] para permitir isto.)

As linhas realçadas em figura 5 Não foram executados por qualquer um dos meus testes, Então eu preciso elaborar um teste que faz com que eles executar se quero cobertura completa.

Se blanket.js a trabalhar, seguindo estes passos:

  1. Baixá-lo http://blanketjs.org/.
  2. Adicioná-lo ao seu projeto
  3. Atualize sua página de equipamento de teste (QuizUtil_test.html no meu caso) como segue:
    1. O código de referência
    2. Decore seu <script> referência como este:
    <script tipo= text/javascript"" src="QuizUtil.js" dados-capa></script>

Blanket.js pega o atributo "dados-capa" e faz sua mágica.  Ganchos em Qunit, atualiza a interface do usuário para adicionar a opção "Ativar cobertura" e voila!

Resumo (TL; DR)

Use Qunit para escrever seus casos de teste.

  • Faça o download
  • Adicioná-lo ao seu projeto
  • Escrever uma página de teste arnês
  • Criar seus testes
    • Alguns dos seu código seja testável refatorar
    • Ser criativo!  Acho que de loucura, impossíveis cenários e testá-los de qualquer maneira.

Use blanket.js para garantir a cobertura

  • Certifique-se de que qunit está funcionando
  • Baixar blanket.js e adicioná-lo ao seu projeto
  • Adicioná-lo à sua página de equipamento de teste:
    • Adicionar uma referência a blanket.js
    • Adicionar um atributo "dados-capa" para seus <script> Tag
  • Executar testes Qunit.

Eu nunca fiz isso antes e tinha umas coisas rudimentares, trabalhando em um punhado de horas. 

Teste feliz!

</fim>

undefinedSubscreva ao meu blog.

Siga-me no Twitter em http://www.twitter.com/pagalvin