Я примерно так и думал. Но что же делать, если мой вклад в приколы первого апреля немного меньше ленты или вконтакте. Так давайте теперь вообще ничего не делать и любую инициативу, сделанное дело и т.п. рубить на корню.
В общем — я подкинул, пусть мааленькую (5 строк кода), но фишечку в копилку первого апреля!
Товарищи минусующие — объясните пожалуйста причину!
П.С. Для тех кто не нашёл — тыкать на ссылку со знаком «бесконечности» много и часто — экран превращается в гипножабу :)
Т.е. мы заменяем полноценные тесты дополнительными проверками в коде (которые или выкидывают исключение, или завершают программу с ошибкой). Не легче ли снабдить исходные коды папочкой tests и и сключать эту папку из финальной сборки?
Существуют и не такие совестливые люди. После НГ корпоратива, часа так в 4 утра я в своём подъезде нашёл (sic!) ключи + брелок от машины. Выйдя из подъезда и нажав на кнопку я малось офигел — Mazda CX-7. Оставил визитку под дворником. Так этот мудак стучал по машине — видно выискивал брелок по писку. Когда я вышел — даже спасибо не сказал. Я с трудом подавил в себе желание гвоздиком через весь бок написать ЖМОТ. Да и машинка тут причём?
Reflection это очень-очень медленно и использовать его в интенсивных (даже ещё не нагруженных) проектах — есть зло и напрасная утилизация процессорного времени. И кстати, это может поломаться в любой момент при использовании кешеров опкода.
У deluge есть и прекрасная веб-морда. Использую её. И даже торрент-файл можно добавить прямо с морды, выбрать нужные файлы и поставить качаться. Плюс — watch-directory тоже отлично работает.
Ёханый бабай. О чем мы сейчас говорим? Тред на 40 комментариев на тему не просто велосипеда, а колеса к нему. Господа, ИМХО тут не школа новичков программирования и эта тема — пустая совершенно. Я с радостью расскажу в личку многоуважаемому Lanrete как бы сделал эту задачу я при условии: а) просьбы; б) более полной исходной картины — имеющиеся ресурсы, возможность использования мемкеша, БД, файлов и т.д.
Но это не тема для топика.
Как-то нелогично использовать для setDelay($iSeconds) секунды, а для setLifetime($iMinutes) минуты.
Дисклеймер — в код не заглядывал. Вывод сделан на основе комментариев в коде.
// устанавливаем нижний предел заполнения формы в 2 секунды
$bform->setDelay(2);
// устанавливаем верхний предел заполнения формы в 60 минут
$bform->setLifetime(60);
Для таких вещей надо ввести кеширование предыдущего результата на серверной стороне и отдавать предыдущий пока не накопился новый. Как только готов новый объект/массив — кешировать его. И всё. Тогда мгновенно можно будет показать результат вычислений.
Путь 2 — пусть себе висит запрос пока не сгенерируется ответ. По окончании всё равно результат приедет в функцию success. Однако при этом пользователь ближайшие 10-20 секунд (время генерации) будет сидеть без данных.
class UserTest extends PHPUnit_Framework_TestCase {
public static function setUpBeforeClass() {
DB_Migrate::load()->users;
}
public function testGetUser() {
$oUser = new UserModel(1);
$this->assertEquals(DB_Migrate::get()->users[1]['name'], $oUser->getName(), 'User load failed');
// Вместо
// $this->assertEquals('Vasya', $oUser->getName(), 'User load failed');
}
}
При этом, таблица users будет уже заполнена нужными данными из миграции и при изменении тестового набора данных этот тест упадёт. Не каждый объект снабжён сеттерами и делать из мне не интересно, если я тестирую ЗАГРУЗКУ и ПОДГОТОВКУ данных объекта. Сеттеры тестировать конечно надо, но не в первую очередь. Я не об этом говорил.
В Вашем (и многоуважаемого VoICh) случае 'Vasya' — магическая переменная.
Я пока обхожусь миграциями с версионностью. Также, постоянно в объекте миграций хранится массив данных, которые когда-либо были загружены и т.п. Таким образом убирается хардкод тестовых данных по типу $this->assertEquals($oModel->getName(3), 'Vasya');
Кстати — есть ещё несколько полезных методов, кроме setUp() и tearDown() — setUpBeforeClass() и т.д. Т.е. для всего теста можно загружать неизменяющиеся данные не на этапе подготовки тестов (что будет прекрасной утилизацией процессорного времени, но зря, если какой-либо тест упадёт до использования данных), а при инстанциировании класса теста.
А у меня аккурат через 2 месяца дочь родится (прогноз — 4 июня +- 2 недели). Куда уж мне :)
В общем — я подкинул, пусть мааленькую (5 строк кода), но фишечку в копилку первого апреля!
П.С. Для тех кто не нашёл — тыкать на ссылку со знаком «бесконечности» много и часто — экран превращается в гипножабу :)
Но это не тема для топика.
Дисклеймер — в код не заглядывал. Вывод сделан на основе комментариев в коде.
Путь 2 — пусть себе висит запрос пока не сгенерируется ответ. По окончании всё равно результат приедет в функцию success. Однако при этом пользователь ближайшие 10-20 секунд (время генерации) будет сидеть без данных.
При этом, таблица users будет уже заполнена нужными данными из миграции и при изменении тестового набора данных этот тест упадёт. Не каждый объект снабжён сеттерами и делать из мне не интересно, если я тестирую ЗАГРУЗКУ и ПОДГОТОВКУ данных объекта. Сеттеры тестировать конечно надо, но не в первую очередь. Я не об этом говорил.
В Вашем (и многоуважаемого VoICh) случае 'Vasya' — магическая переменная.
Кстати — есть ещё несколько полезных методов, кроме setUp() и tearDown() — setUpBeforeClass() и т.д. Т.е. для всего теста можно загружать неизменяющиеся данные не на этапе подготовки тестов (что будет прекрасной утилизацией процессорного времени, но зря, если какой-либо тест упадёт до использования данных), а при инстанциировании класса теста.