в firebug работает только эта конструкция. я понимаю, что примеры нужно запускать из внешнего файла. вопрос в другом: почему эта конструкция вообще работает в дефолтном js, возвращая список из 23-х нулей?
Поиглася в gimp. Достаточно уменьшить масштаб изображения на 1px, в любом измерении, и надпись VOID при сжатии не проявляется, при любом коэффициенте. Но появляются темные и светлые пятна, интенсивность которых зависит от выбранного алгоритма интерполяции.
не отработает в данной ситуации как нужно и не найдет Сашу, поскольку LIKE не умеет парсить списки, извлекать значения и трактовать их как аргументы для сравнения с шаблоном. ’Ваня, Саша’ в данном случае неатомарное значение типа список строк. Чтобы научить SQL работать с такими данными, нужно либо расширить язык, либо упростить модель до 1NF. Декомпозиция до 1NF достигается разбиением составного значения на атомарные
Кажется здесь критерием отбора служит часть слова — буква. Не значит-ли это, что атомарными значениями в данном являются буквы алфавита, а не имена?
Или по другому задам вопрос: как, с точки зрения 1NF, понимать «атомарность»?
Правильно понимаю, что «детали» такого контракта нужно прописывать возле каждого метода, где упоминаются часы — принимаются аргументами или возвращаются в результате? Если так, то тип кажется выгоднее — здесь реализация будет инкапсулирована внутри единтсвенного класса.
@Ensures({
"result >= 0",
"result <= 23"
})
int getHour();
Кажется, проблема этого кода в том, что getHour() возрващает абстактный int, вместо собственно «часов». Если завести специальный тип Hour (у нас ведь ООП в конце-концов), то вся эта атрибутика будет не особенно нужна:
Тесты — суть выражение функциональных спецификаций. Если в тесте не отражены (явно или же очевидным образом) какие-то условия, считайте что на них нет постановки. В самом деле, постановка может быть не полной. Но в этом виновата лишь ваша лень — при чем тут TDD? :) Кстати, тут могут быть полезны вот такие феньки, которые выводят лейаут теста на «человеческом» языке — обратно, в виде спецификации.
Если вы делаете одно простое изменение в коде, и вам нужно перелопатить десяток тестов, это означает что вы поменяли шаги местами. сначала меняется один тест — затем вносится изменение в код.
В процессе выполнения теста создаются идеальные условия для дебага.
Если одно и то же изменение в коде вызывает каскадное изменение других тестов, это является сигналом о сильной связанности — т.е. ваша система тестов попросту плохо спроектирована. (сюрприз, чтобы тесты было легко поддерживать, их тоже необходимо вдумчиво проектировать — так же тщательно как и любой другой код. поэтому как раз-таки для «быдлокодеров» от ни нет ни какой пользы).
В принципе, я согласен. Но есть вырожденные ситуации, где, как мне кажется, это может быть полезно.
Например, если ваше приложение и есть инсталлятор — где инициализация virtualenv лишь первый шаг, а дальше накладываются пачти, создаются конфиги и т.п.
Я использую такую возможность в скрипте, запускающем тесты для проекта. Это создает единую точку входа, упрощая интеграцию с CI-сервером. А «интегрированный» деплоймент позволяет лишний раз убедиться, что все зависимости прописаны.
У pip есть замечательная фича — он умеет создавать бандлы (bundle) для установки всех зависимостей «оффлайн». Единственная проблема — для распаковки бандла на целевом хосте должен быть установлен сам pip, желательно не самый старый. Путем такого трюка с virtualenv это ограничение достаточно легко обходится.
согласен. в принципе, тем хуже для примера. здесь я хотел показать, что virtualenv'у, устанавливаемому таким способом, можно передавать знакомые параметры.
ага, это поиск. вы сами выбираете скорость, с которой хотите приближаться к цели. будете идти мелкими шагами — выйграете в контроле, но проиграете в темпе. крупными шагами — наоборот — пойдете быстро, но можете «не вписаться в поворот» и пролететь мимо. со временем найдете оптимальный.
все известные мне тест-фреймоврки содержат асерты для сравнения значений с учетом типа. PhpUnit::assertSame(), например. либо напишите в асерте count() === 10 — если вернет не число, тоже увидите fail.
ps: для неформализованных требований вы вряд-ли сможете написать тест ;)
Вот только на этом компьютере у Васи, а на остальных двух сотнях работает. У него там, правда, кондёры на материнке полететели, но программа ведь все-равно должна работать, правда?
что «правда»? требовние работать на уникальном компрьютере Васи с полетевшими кондерами было с самого начала? если да, то вы этот кейс должны были уже вусмерть затеститровать. а если же нет — это либо нарушение технических требований (оборудование должно быть исправно), либо новая фича, за отдельные деньги. при чем тут tdd? тесты — это не только юнит тесты.
ага, no school наше фсё. ;)
нормализация это один из методов анализа предметной области. денормализация — прием, используемый в процессе синтеза решения.
в firebug работает только эта конструкция. я понимаю, что примеры нужно запускать из внешнего файла. вопрос в другом: почему эта конструкция вообще работает в дефолтном js, возвращая список из 23-х нулей?
Кажется здесь критерием отбора служит часть слова — буква. Не значит-ли это, что атомарными значениями в данном являются буквы алфавита, а не имена?
Или по другому задам вопрос: как, с точки зрения 1NF, понимать «атомарность»?
Кажется, проблема этого кода в том, что getHour() возрващает абстактный int, вместо собственно «часов». Если завести специальный тип Hour (у нас ведь ООП в конце-концов), то вся эта атрибутика будет не особенно нужна:
В чем смысл?
Если вы делаете одно простое изменение в коде, и вам нужно перелопатить десяток тестов, это означает что вы поменяли шаги местами. сначала меняется один тест — затем вносится изменение в код.
В процессе выполнения теста создаются идеальные условия для дебага.
Если одно и то же изменение в коде вызывает каскадное изменение других тестов, это является сигналом о сильной связанности — т.е. ваша система тестов попросту плохо спроектирована. (сюрприз, чтобы тесты было легко поддерживать, их тоже необходимо вдумчиво проектировать — так же тщательно как и любой другой код. поэтому как раз-таки для «быдлокодеров» от ни нет ни какой пользы).
Например, если ваше приложение и есть инсталлятор — где инициализация virtualenv лишь первый шаг, а дальше накладываются пачти, создаются конфиги и т.п.
Я использую такую возможность в скрипте, запускающем тесты для проекта. Это создает единую точку входа, упрощая интеграцию с CI-сервером. А «интегрированный» деплоймент позволяет лишний раз убедиться, что все зависимости прописаны.
У pip есть замечательная фича — он умеет создавать бандлы (bundle) для установки всех зависимостей «оффлайн». Единственная проблема — для распаковки бандла на целевом хосте должен быть установлен сам pip, желательно не самый старый. Путем такого трюка с virtualenv это ограничение достаточно легко обходится.
Если нужные зависимости прописать в файл requirements.pip, например:
и добавить в начало запускающего модуля вашего проекта вот такой код:
тогда все необходимое установится автоматически при первом запуске скрипта, и сразу же станет доступным к использованию.
ps: для неформализованных требований вы вряд-ли сможете написать тест ;)
что «правда»? требовние работать на уникальном компрьютере Васи с полетевшими кондерами было с самого начала? если да, то вы этот кейс должны были уже вусмерть затеститровать. а если же нет — это либо нарушение технических требований (оборудование должно быть исправно), либо новая фича, за отдельные деньги. при чем тут tdd? тесты — это не только юнит тесты.