месечни архиви: Януари 2014

Бедният човек на кеширане в JavaScript

[TL;Д-р версия: използва бисквитки за да съхранява резултатите от async повиквания; сравнимостта на резултатите от минали async повиквания веднага и след това ги утвърждава след зареждане на страницата.]

Съм бил на работа в интранет сайта на SharePoint за клиент, което функции, наред с други неща, стилизирана допълнителна навигация, чието меню опции се управляват чрез редовни стар списък по избор.  Идеята е, че клиентът получава за контрол на сайта "тяхната" меню без чувства или са засегнати от глобалната навигационна, изведен от нея.

(има нещо невероятно подривни за добавянето на CEWP, който сочи към HTML файл, който зарежда някои CSS и JS да променят фундаментално почти всичко за поведението на даден сайт..., но това е за друг пост)

Кодът за тази доста проста:

  • Изчакайте страницата да завърши зареждането и асинхронно повикване към товаря горе меню елементи от списък с помощта на почивка или lists.asmx или каквото и
  • Използване на jQuery, динамично пренесат китка, ако <Li>снимки на вътре родител <UL> (Вижте Кристиан Pinder статия тук за опростено обяснение на това tecnnique)
  • Използвайте CSS за цялото форматиране
  • Печалба!

Възпалено място тук е, че всеки път, когато някой удари един от страници на сайта, този потребител уеб браузър се достига до получите елементи от списъка.  След като dev е пълна и изпитване е доказано неща, за да бъде стабилна и пълна, тази покана е необходимо повече от 99% на времето, тъй като менюто рядко промени.  Тя също има странни UI влияние, което е често срещани в този смел нов свят на хипер-ajaxy уеб сайтове – страницата се рендира и само тогава прави менюто.  Той е нервен и разсейващи по мое мнение.  И нервност. Така, кеширане. 

Аз промяна логиката thusly:

  • Потърсете "бисквитка" в браузъра, която съдържа менюто, тъй като аз последно го прочетете
    • Ако намерени, направи го веднага.  Не чакайте за страницата, за да завърши зареждането.  (Трябва да се уверете, че HTML е стратегическо място тук, но това не е трудно да се направи).
  • Изчакайте страницата да завърши зареждането и асинхронно повикване към товаря горе меню елементи от списък с помощта на почивка или lists.asmx или каквото и
  • Сравнете това, което получих срещу бисквитката
    • Ако тя съвпада, Стоп
    • В противен случай, използване на jQuery, динамично пренесат китка, ако <Li>снимки на в <UL>
  • Използвайте CSS за цялото форматиране
  • Печалба!

Някои от вас ще кажат, "Ей! Няма реален кеширане връщане тук, тъй като вие сте четене на менюто все пак всеки път.”  И вие сте прав-не съм дава сървъра всякакъв вид на почивка.  Но тъй като повикването е готино и се случва след първоначалните констатации на страницата HTML payload напълно прави, Той се "чувства" по-отзивчиви към потребителя.  Менюто прави доста много, тъй като страницата равенства.  Ако менюто се случва с промяната, потребителят е подложен на нервност водих на менюто, но само че едно време.

Има няколко начина да направите това кеширане по-ефективно и да помогне на сървъра в същото време:

  • В едно правило, че кеша на"бисквитка" е валиден за най-малко 24 часове или някои други срокове. Както дълъг както там е не издишвам бисквит, Използвайте бисквитка меню снимка и никога не хит на сървъра.

Ами..., това е всичко, което дойде на ум в момента :). 

Ако някой има някакви умни идеи тук бих искал да ги знаят.

И на последно място-тази техника може да се използва за други неща.  Този клиент страница има няколко неща, данни задвижване на различни страници, много от тях промяна сравнително рядко (като веднъж седмично или веднъж месечно).  Ако насочвате конкретни области на функционалност, Можете да дадете по-отзивчиви потребителски интерфейс чрез издърпване на съдържанието от местните бисквитка се съхранява и оказване незабавно.  Той се чувства по-бързо за потребителя дори ако не записвате сървъра всички цикли.  Вие може да запишете на сървъра цикли от вземане на решение за някои условията и предпоставките да обезсили кеш тази местна бисквитка.  Това е всички ситуационни и artsy неща и наистина най-забавно :). 

</край>

undefinedАбонирайте се за моя блог.

Следвайте ме на Twitter в http://www.twitter.com/pagalvin

Как да: Конфигуриране на единица тест и тест покритие с QUnit.js и Blanket.js за офис 365 SharePoint App

Интро

Аз съм бил проучване на единица тестване и тест покритие за JavaScript, като работя върху нов SharePoint ап за SharePoint онлайн в офиса 365 апартамент.  Очевидно изследвания пътища ме накара да Qunit.js и веднага след това, за да Blanket.js.

QUnit нека да настроите единица тестове и ги групират в модули.  Един модул е само един прост начин за организиране на свързани тестове. (Аз не съм сигурен, аз съм го използва по предназначение, но това е работа за мен досега с малък набор от тестове, до този момент са дефинирани).

Blanket.js се интегрира с Qunit и тя ще ми покаже действителния линии на JavaScript, които бяха — и по-важното – не са били действително извършените в хода на изпълнение на тестовете.  Това е "покритие" – линии, които изпълняват са обхванати от изпитването, докато други не са.

Между създаването на добри тестови случаи и показване на покритие, Ние може да намали риска, че нашия код има скрити дефекти.  Добри времена.

Qunit

Ако приемем, вие имате вашия Visual Studio проект създаден, от свалянето на JavaScript пакет от http://qunitjs.com.  Добавяне на JavaScript и съответните CSS към вашето решение.  Мина изглежда така:

image

Фигура 1

Както можете да видите, Аз бях с помощта 1.13.0 по това време написах този блог пост. Не забравяйте да изтеглите и добавяне на CSS файла.

Това на пътя, следващата стъпка е да се създаде някакъв вид на тест впрегне и позоваване на Qunit бита.  Аз съм тестване куп функции в скрипт файл, наречен "QuizUtil.js", така че съм създал една HTML страница, наречена "QuizUtil_test.html", както е показано:

image Фигура 2

Тук е кодът:

<!DOCTYPE HTML>
<HTML xmlns= "http://www.w3.org/ 1999/xhtml">
<главата>
    <заглавие>QuizUtil тест с Qunit</заглавие>
    <връзка отн= "стилове" HREF="../CSS/qunit-1.13.0.CSS" />
    <скрипт тип= текст/javascript"" SRC="QuizUtil.js" данни-корица></скрипт>
    <скрипт тип ="текст/javascript" SRC ="qunit-1.13.0.js"></скрипт>
    <скрипт тип ="текст/javascript" SRC ="blanket.min.js"></скрипт>

    <скрипт>
        модул("getIDFromLookup");
        тест("QuizUtil getIDFromLookupField", функция () {
            var goodValue = "1;#Пол Galvin";

            равни(getIDFromLookupField(goodValue) + 1, 2), "ИД на [" + goodValue + "] + 1 трябва да бъде 2";
            равни(getIDFromLookupField(неопределен), неопределен, "Undefined входен аргумент трябва да се върне недефиниран резултат.");
            равни(getIDFromLookupField(""), неопределен, "Празни входен аргумент трябва да връща стойности на недефиниран.");
            равни(getIDFromLookupField("gobbledigood3-thq;dkvn ада;skfja sdjfbvubvqrubqer0873407t534piutheqw;VN"), неопределен,"Трябва да връща винаги резултат конвертируема до цяло число");
            равни(getIDFromLookupField("2;#друго лице"), "2", Проверка на" [2;#друго лице].");
            равни(getIDFromLookupField("9834524;#дълги стойност"), "9834524", "Голяма стойност тест.");
            notEqual(getIDFromLookupField("5;#всеки", 6), 6, "Изпитване на notEqual (5 не е равно на 6 за тази проба: [5;#всеки]");

        });

        модул("htmlEscape");
        тест("QuizUtil htmlEscape()", функция () {
            равни(htmlEscape("<"), "&lt;", "Бягство на по-малко от оператора ('<')");
            равни(htmlEscape("<DIV клас =  "someclass">Някакъв текст</DIV>"), "&lt;DIV клас =&как много;SomeClass&как много;&gt;Някакъв текст&lt;/DIV&gt;", "По-сложни тестовия низ.");
        });

        модул("getDateAsCaml");
        тест("QuizUtil getDateAsCaml()", функция () {
            равни(getDateAsCaml(нов Дата("12/31/2013")), "2013-12-31T:00:00:00", "Изпитване на твърди кодирани дата: [12/31/2013]");
            равни(getDateAsCaml(нов Дата("01/05/2014")), "2014-01-05T:00:00:00", "Изпитване на твърди кодирани дата: [01/05/2014]");
            равни(getDateAsCaml(нов Дата("01/31/2014")), "2014-01-31T:00:00:00", "Изпитване на твърди кодирани дата: [01/31/2014]");
            равни(getTodayAsCaml(), getDateAsCaml(нов Дата()), "getTodayAsCaml() трябва да се равнява getDateAsCaml(нова дата())");
            равни(getDateAsCaml("глупости стойност"), неопределен, "Опитайте се да получите датата на глупост стойност.");
            равни(getDateAsCaml(неопределен), неопределен, "Опитайте се да получите датата на [неопределен] дата.");
        });

        модул("getParameterByName");
        тест("QuizUtil getParameterByName (от низа на заявката)", функция () {
            равни(getParameterByName(неопределен), неопределен, "Опитайте се да получите недефиниран параметър трябва да се върне недефиниран.");
            равни(getParameterByName("не съществува"), неопределен, "Опитайте се да се получи стойност на параметър, когато знаем, че параметърът не съществува.");

        });

        модул("Бисквитките");
        тест("QuizUtil различни бисквитка функции.", функция () {
            равни(setCookie("тест", "1", -1), getCookieValue("тест"), "Get бисквитка задам трябва да работи.");
            равни(setCookie("anycookie", "1", -1), вярно, "Определяне на валиден готвене трябва да се върне"истина".");
            равни(setCookie("луд Бисквитеното име !@#$%"%\^&*(()?/><.,", "1", -1), вярно, "Въвеждане на лош бисквитка име трябва да се върне"неистина".");
            равни(setCookie(неопределен, "1", -1), неопределен, "Минаваща неопределени като името на бисквитката.");
            равни(getCookieValue("не съществува"), "", "Бисквитката не съществува тест.");
        });

    </скрипт>
</главата>
<тяло>
    <DIV ИД= "qunit"></DIV>
    <DIV ИД= "qunit-приспособление"></DIV>

</тяло>
</HTML>

Има няколко неща, случва тук:

  1. Съотнасяне ми код (QuizUtil.js)
  2. Съотнасяне Qunity.js
  3. Определяне на някои модули (getIDFromLookup, Бисквитки, и други)
  4. Поставяне <DIV> чието име е "qunit".

След това, Аз просто дръпнете тази страница и да получите нещо подобно:

image

Фигура 3

Ако погледнете в началото, имате няколко опции, две от които са интересни:

  • Скрий преминали тестове: Доста очевидно.  Може да помогне на очите си просто вижте на проблемните области и не е много елементарно.
  • Модул: (падащо меню): Това ще филтрира тестовете до само тези групи тестове искате.

Що се отнася до тестовете се – няколко коментари:

  • Разбира се че трябва да напишете кода си, така че на първо място е проверимо.  С помощта на инструмента може да ви помогне да наложат тази дисциплина. Например, Имах функция, наречена "getTodayAsCaml()”.  Това не е много проверимо, тъй като тя отнема не входен аргумент и да го тестват за равенство, Ние ще трябва да обновяваме изпитване код, за да отрази текущата дата.  Аз го refactored чрез добавяне на параметър за въвеждане на данни след това преминаване на текущата дата, когато искате днешна дата в CAML формат.
  • Qunit рамка документи собствените си изследвания и изглежда доста здрав.  Тя може да направи прости неща като проверка за равенство и също така има поддръжка за Аякс стил повиквания ("истински" или подиграване използването любимите си mocker).
  • Преминава през процеса и ви принуждава да мисли чрез крайни случаи – какво се случва с "неопределен" или null е преминала в функция.  Това го прави мъртъв просто да тествате тези сценарии вън.  Добри неща.

Покритие с Blanket.js

Blanket.js допълва Qunit чрез проследяване на действителните редовете с код, който изпълнява в хода на пуснете тестове.  Тя интегрира право в Qunit така че въпреки че това е цяла отделна ап, Тя играе добре – тя наистина изглежда като това е една непрекъсната ап.

Това е blanket.js в действие:

image Фигура 4

image

Фигура 5

(Всъщност трябва да щракнете върху квадратчето "Активиране на покритие" в горната част [виж фигура 3] за да разрешите това.)

Маркираната линии на фигура 5 не са били изпълнени от някоя от моите тестове, така че аз трябва да създаде тест, който да ги накара да изпълни, ако искам пълно покритие.

Вземи blanket.js работи като следвате тези стъпки:

  1. Го изтеглите от http://blanketjs.org/.
  2. Го добавите към вашия проект
  3. Актуализиране на тестовата ви страница сбруя (QuizUtil_test.html в моя случай) както следва:
    1. Референтен код
    2. Украсяват вашия <скрипт> референтен подобно:
    <скрипт тип= текст/javascript"" SRC="QuizUtil.js" данни-корица></скрипт>

Blanket.js взима атрибута "данни-корица" и прави своята магия.  Куките в Qunit, актуализира интерфейс, за да добавите опцията "Разреши покритие" и готово!

Резюме (TL; Д-Р)

Използвайте Qunit, за да напишете вашия тест случаи.

  • Изтеглете го
  • Го добавите към вашия проект
  • Пишете тест впрегне страница
  • Създайте си тестове
    • Някои от вашите код да бъде проверими refactor
    • Бъдете креативни!  Мисля на луд, невъзможно сценарии и ги тест все пак.

Използвайте blanket.js, за да осигури покритие

  • Проверете дали Qunit работи
  • Изтегляне blanket.js и да го добавите към вашия проект
  • Го добавите към вашия тест впрегне страница:
    • Добавяне на препратка към blanket.js
    • Добавяне на "данни-корица" атрибут към вашия <скрипт> етикет
  • Направи свой тестове за Qunit.

Аз никога не е направил това преди и има някои елементарен неща работи в няколко часа. 

Честит тестове!

</край>

undefinedАбонирайте се за моя блог.

Следвайте ме на Twitter в http://www.twitter.com/pagalvin