Делаем все то же самое, но генерированный шум дублируем с отзеркаливаем по горизонтали и вертикали. Теоретически должно получиться, на практике — не пробовал. Про подсветку, конечно, забываем.
Тут все зависит от прибыли от работы. Если она составляет чуть более прожиточного минимума, то эта «работа» так и останется в состоянии «сколько можно сидеть за этим твоим компутером». А если семья за счет этой работы ест, пьет и ни в чем себе не отказывает, то на семью озарение снисходит крайне скоро.
Работа в интернете — это такая же работа, как и любая другая. Если работаешь на себя, но это работа с плавающим графиком. И тут уже от тебя зависит, будешь ты «сверхурочить» или нет. Только почему-то в других профессиях это называется «трудоголик», а у нас — «задрот». Ну или «облуч», если так угодно. Впрочем, ни первый, ни второй вариант не верны в корне.
Это аналогия не по смыслу, а по степени тупости «кинутого». Тут при поездке в другой город-то стараешься много по телефон не трещать, а эти двое интернов в другой стране качают. Степень атрофии мозга переваливает за все мыслимые пределы.
А не сильно мозги напрягаются от постоянной мысли о том, что нельзя давать в долг незнакомому человеку на улице под честное слово? А то ведь кинуть могут. Ситуация с мегафоном недалеко от этой ушла.
В таких случаях используются фабрики и генераторы фейковых объектов для наполнения тестовой базы. Да, кстати, о тестовой базе. Она должна быть в любом случае.
В инструментах на PHP, к сожалению, не искушен, но можете посмотреть FFaker и Fabricator для Ruby, чтобы понять, о чем я говорю.
Расписано, безусловно, толково, но это не TDD. Как было верно указано в начале статьи, тест должен не тестировать, а описывать поведение программы. Т.е. тест должен придумываться задолго до коммита или вопроса начальника. Написали тест — написали код — подтвердили прохождение теста — закоммитили.
Сами тесты же должны браться из ТЗ, спеки или переговоров с заказчиком. Вы же, в конце концов, знаете, что должна делать ваша программа — ну так и описывайте. Лично для себя я выбрал метод «от общего к частному». Т.е. сначала я описываю общий функционал отдельного модуля/страницы, затем, по выполнении общих тестов, описываю мелкие детали и частные случаи. Если эти тесты валятся — правлю код. Это очень удобно, т.к. не требует изначального утомительного описывания каждого чиха программы.
ЗЫ. Я не яблоненавистник, у самого айфон
В инструментах на PHP, к сожалению, не искушен, но можете посмотреть FFaker и Fabricator для Ruby, чтобы понять, о чем я говорю.
Сами тесты же должны браться из ТЗ, спеки или переговоров с заказчиком. Вы же, в конце концов, знаете, что должна делать ваша программа — ну так и описывайте. Лично для себя я выбрал метод «от общего к частному». Т.е. сначала я описываю общий функционал отдельного модуля/страницы, затем, по выполнении общих тестов, описываю мелкие детали и частные случаи. Если эти тесты валятся — правлю код. Это очень удобно, т.к. не требует изначального утомительного описывания каждого чиха программы.