Waliter Irlandec

Ну тесты бываю разными: и зелеными и красными. ))

Все зависит от уровня абстракции, который хочется протестировать. Поэтому тесты и делятся на всяческие классификации. Например: юнит (модульные) тесты, интеграционные тесты и т.д. и т.п.

Я как ярый сторонник BDD использую два типа тестов feature (читай интеграционные тесты) и spec (читай юнит тесты)

Итак, features. Берем Behat и херачем кучу тестов по типу:
Зашел на главную,
Потыкал чего-то в форме регистрации
Зашел в профиль и увидел свое имя и фотку на странице
Profit!

Вот в целом и получили: "Непосредственно регистрация с занесением в БД", только в этой ситуации нам абсолютно не важно что там в БД. Нам важно чтобы пользователь зарегистрировался и попал в закрытый раздел сайта.

Для таких тестов хорошо иметь поддержку окружения (prodaction, development, test) в коде, чтобы например можно было капчу отключить или еще какую сложную лабуду не делать.
Если система замудрена до ужаса придется здесь для тестов все окружение поднимать. А лучще вообще отдать CI такое делать пусть друг трудится.
Плюс таких тестов например когда пишем сложный фронт - сложный бек и еще более сложнейший бек-бек, то можно одним чохом протестировать работу всего сервиса.

Следующий уровень абстракции spec:

Если нам в интеграционных тестах было немного пофиг на БД. Она как бы пишет, но что так за структура абсолютно пофиг. То в случае со спекими нам ВАЩЕ ПОФИГ.
Мы берем наш класс (функцию) и проверяем что за результаты она отдает. Вместо объектов, с которыми подопытный (объект тестируемого класса), даем ему резиновую бабу (моки и т.п), и смотрим на результаты нашего труда.

Главное при том и другом подходе нам без разницы, что у нас в кишках мы всегда тестируем публичные свойства системы. В первом случае это реакция на пользователя, во втором публичное API класса.

Вот как то так!

P.S тесты надо бы писать до кода.

1. Самое простое - Watermark.
2. Сложнее - частичная доставка с сервера выбранной области изображения с шифрованием и расшифровкой на клиенте, и никогда не отображать изображение целиком. (т.е. типа контейнера со скроллом внутри канваса по аналогии с гугл-мапс).
3. Хардкорный стиль - Adobe Flash Application!
4. "Puzzle" - "хаотичная" (только с виду!) динамическая нарезка в режиме спрайт-карты и сборка через js. Формула - тоже разная каждый раз.
5. "Калька" - многослойное изображение из нескольких с альфа-каналом (с прозрачностью)
6. Класть изображение в JS-контейнер на серверной стороне, помещая в него метод отображения с привязкой к IP и браузеру клиента, и ровно на 15 секунд (чтобы загрузил и всё) и бинарные шифрованные данные, после загрузки скрипта у клиента - запрашивать токен с сервера на расшифровку данных.
(методы можно комбинировать)

У вас получается при преобразовании объекта, вот такой селектор:
$("[object Object] #resp")

Вот так должно сработать:

$($(this).attr('id') + " #resp").text(response);
// Или
$(this.id + " #resp").text(response);

Так можно сразу по ID обращаться.
Ну или так:
$("#resp", $(this)).text(response);

У меня для мультисайтовости с одной бд используются префиксы, которые автоматически добавляются к email, в зависимости от сайта.
Единственный момент, нужно убирать префиксы перед выводом email на экран.

Это реализация механизма подписок pub/sub.
Используется примерно так:

подписка на события

obj.on('fire',function(data){
    //здесь обработка события
});

вызов
obj.trigger('fire',data);

codepen.io/cleric/pen/dIuFj

гляньте на фреймворки, люди уже собаку на этом съели.
Symfony2, Phalcon, Zend2, Yii и т.д.

function1();
function2();
function3();

Куда уж изящнее?

UPD:
Допустим, каждая функция нам может сказать, когда там у нее внутри всякие процессы позавершаются, и говорить она будет через callback:

function func1(callback) {
    ...
}

Предположим, что у нас есть N подобных функций, сделаем последовательность из них:
var funcQueue = [func1, func2, ..., funcN];
Теперь:

function callSequently(funcQueue) {
    if(funcQueue.length) {
        (funcQueue.shift())(function() {
            callSequently(funcQueue);
        });
    }
}
callSequently(funcQueue);

Что-то я намудрил здесь... Но пусть будет.

Код выше вполне нормальный. Последние две строчки можно объединить, на работе скрипта это не скажется. Но тут есть один момент. Шаблон - это обычно html-текст, и php-инструкции в нём чужеродные (с точки зрения html), и даже расширения таких файлов обычно делают не .php, а .phtml - чтобы подчеркнуть, что это не php-скрипт с кодом. Поэтому в таких случаях используют специальный формат записи php-инструкций, причём обычно пытаются одну команду расположить в одну строчку, и не смешивать php и html в одной строчке. С этой точки зрения лучше не объединять эти две строчки в одну инструкцию php.
Я обычно не пишу скобки, как в коде выше, я использую второй вариант открытия и закрытия блоков, без фигурных скобок:

<div id="container">
<?php if ($count>0): ?>
    <?php foreach($items as $item): ?>
        <div class="item"><?=$item?></div>
    <?php endforeach ?>
<?php endif ?>
</div>

Но лучше поиграйтесь с этим вариантом и переходите на внешний шаблонизатор, например Twig. (вот есть урок по его встраиванию в сайт без фреймворка)

$(".class1").each(function() {
    total += parseInt($(this).text());
});

var sum = 0;
$('.class').each(function(){sum +=parseInt($(this).text())});

Если я правильно понял, то речь идёт о многоступенчатом заполнении формы. Тогда в самом простейшем случае можно использовать сессию.

setTimeout(function(){
  $('button').trigger('click');
}, 1000);

<select class="form-control" name="cpu">
	<option value="1">1CPU</option>
	<option value="2">2CPU</option>
	<option value="3">3CPU</option>
	<option value="4">4CPU</option>
</select>