все известные мне тест-фреймоврки содержат асерты для сравнения значений с учетом типа. PhpUnit::assertSame(), например. либо напишите в асерте count() === 10 — если вернет не число, тоже увидите fail.
ps: для неформализованных требований вы вряд-ли сможете написать тест ;)
Вот только на этом компьютере у Васи, а на остальных двух сотнях работает. У него там, правда, кондёры на материнке полететели, но программа ведь все-равно должна работать, правда?
что «правда»? требовние работать на уникальном компрьютере Васи с полетевшими кондерами было с самого начала? если да, то вы этот кейс должны были уже вусмерть затеститровать. а если же нет — это либо нарушение технических требований (оборудование должно быть исправно), либо новая фича, за отдельные деньги. при чем тут tdd? тесты — это не только юнит тесты.
Я пришел к автоматическим тестам очень просто — проанализировав беклог только что закончившейся очень нервной итерации. Проекту — год. Оказалось, что лишь 20% сделанных задач было новыми штуками, которые двигают нас вперед, а 80% задач стало разлинчного рода багофиксингом. Причем в конце итерации, котрый мы «отыгрывали» уже в дополнительное время, было такое ощущение, что всё вышло из под контроля и идет «в разнос» — когда каждая доделка приводит к появлению/выявлению еще пары новых багов — и только каким-то чудом оно в итоге «сошлось».
юнти-тесты это модульное тестирование — для маленьких атомарных единиц функционала. ну не бывает таких здоровых модулей, чтобы сразу и gui и база данных. ;)
нужен метод, возвращающий объект класса MyClass с одним свойством и конструктором с параметром — значением этого свойства.
…
Устал :) В общем ещё с десяток итераций и получим код
— как сделать шаг? — нужно поднять ногу и, сохраняя равновесие, перенести её на 1 милиметр вперед, затем еще на 1 миллиметр, потом еще на 1 миллиметр,… — фу, как сложно ходить! ;)
тест — это та же запись требований, только на языке программирования. у вас тут одно понятное предложение. описывайте в тесте, сразу (и только) то, что требуется. зачем вся эта чехорда?
По-моему это обычное дело, когда заказчик выдвигает абстрактные требования. У него есть какая-то проблема, он не знает как её решить (скажем, потому что не обладает нужными компетенциями), но очень хочет и для этого обращается к разработчику.
Естественно, что заказчик описывает проблему абстрактно: в меру собственного понимания, каких-то ощущений и эмоций. Задача разработчика как раз и состоит в том, чтобы выявить «паталогию», придумать решение и реализовать.
Когда разработчик, не разобравшись в проблеме и не придумав решение, бросается «кодить» — это клиника — такую ситуацию, думаю, можно не рассматривать.
Если ваш заказчик берет на себя функцию принятия технических решений (например, размер шрифта), это скорее всего означает, что в ваших отношениях с ним что-то не так. И вам нужно, в первую очередь, решить этот вопрос. Ведь заказчик менее компетентен в сфере разрботки, нежели вы, и его действия вполне ожидаемо будут неверными. (в таком случае, он тупо будет учиться, на собтсвенных ошибках, — которые скорее всего будут выдаваться за ваши).
Может быть он вам не доверяет? В этом случае постарайтесь доказать свою компетенцию, чтобы у него не было сомнений. А может быть вы сами снимаете с себя ответственность за выработку решений? Тогда естественно эту функцию он будет брать на себя и станет выдумывать решение сам (ведь больше не кому).
в Vista, по умолчанию установлено 96dpi. у меня экран 129dpi и поэтому текст выглядит очень мелко. если выставить в настройках эти самые 129dpi, то текст во многих приложениях перестает помещаться в отведенную ему место.
ага) в принципе, многие телики уже комплектуются ethernet входом/wifi и софтом для просмотра контента из сети, в том числе видеохостингов типа youtube. например samsung C6540
from itertools import permutations
source = "jibw ji jp bw jibw"
words = source.split()
answer = min("".join(combination) for combination in permutations(words))
согласен. но чтобы быть практически значимой, философия решения задачи должна поддерживаться фичами языка.
то, что в python называется поддержкой ФП, в реальности является лишь синтаксическим сахаром, имитацией этой самой парадигмы. например, вот такой ФП-подобный код на «мультипарадигменном» python выглядит вполне органично:
>>> f = lambda (x, y): x + y
>>> a = (1, 2)
>>> f(a)
3
но по сути, он чужеродный, ведь работает очень не эффективно. в процессе выполнения такой программы, в самом деле, создаются переменные, а лямбда распаковывает кортеж в пару локальных объектов. в «настоящих» функциональных языках картина совсем иная, т.к. там нет переменных.
некоторое количество кода, пользующегося хаком в виде разбора стектрейса для доступа к рантайм значениям переменных в вызывающем коде, перестанет работать.
и поделом =) «вызывающий код» для рекурсивной функции это та же самая функция. в этом случае есть более очевидные способы передать значения переменных, нежели стектрейс. :)
Да, так и есть: другое решение, нужно описывать заново — я периодически попадаю в такие ситуации. По-моему, это в порядке вещей — все равно нормальное решение получается лишь с третьего раза. :)
ps: для неформализованных требований вы вряд-ли сможете написать тест ;)
что «правда»? требовние работать на уникальном компрьютере Васи с полетевшими кондерами было с самого начала? если да, то вы этот кейс должны были уже вусмерть затеститровать. а если же нет — это либо нарушение технических требований (оборудование должно быть исправно), либо новая фича, за отдельные деньги. при чем тут tdd? тесты — это не только юнит тесты.
— как сделать шаг? — нужно поднять ногу и, сохраняя равновесие, перенести её на 1 милиметр вперед, затем еще на 1 миллиметр, потом еще на 1 миллиметр,… — фу, как сложно ходить! ;)
тест — это та же запись требований, только на языке программирования. у вас тут одно понятное предложение. описывайте в тесте, сразу (и только) то, что требуется. зачем вся эта чехорда?
Естественно, что заказчик описывает проблему абстрактно: в меру собственного понимания, каких-то ощущений и эмоций. Задача разработчика как раз и состоит в том, чтобы выявить «паталогию», придумать решение и реализовать.
Когда разработчик, не разобравшись в проблеме и не придумав решение, бросается «кодить» — это клиника — такую ситуацию, думаю, можно не рассматривать.
Если ваш заказчик берет на себя функцию принятия технических решений (например, размер шрифта), это скорее всего означает, что в ваших отношениях с ним что-то не так. И вам нужно, в первую очередь, решить этот вопрос. Ведь заказчик менее компетентен в сфере разрботки, нежели вы, и его действия вполне ожидаемо будут неверными. (в таком случае, он тупо будет учиться, на собтсвенных ошибках, — которые скорее всего будут выдаваться за ваши).
Может быть он вам не доверяет? В этом случае постарайтесь доказать свою компетенцию, чтобы у него не было сомнений. А может быть вы сами снимаете с себя ответственность за выработку решений? Тогда естественно эту функцию он будет брать на себя и станет выдумывать решение сам (ведь больше не кому).
выдает bwjibwjibwjijp
последний пример (на си?) тоже императивный функциональный?
то, что в python называется поддержкой ФП, в реальности является лишь синтаксическим сахаром, имитацией этой самой парадигмы. например, вот такой ФП-подобный код на «мультипарадигменном» python выглядит вполне органично:
но по сути, он чужеродный, ведь работает очень не эффективно. в процессе выполнения такой программы, в самом деле, создаются переменные, а лямбда распаковывает кортеж в пару локальных объектов. в «настоящих» функциональных языках картина совсем иная, т.к. там нет переменных.
и поделом =) «вызывающий код» для рекурсивной функции это та же самая функция. в этом случае есть более очевидные способы передать значения переменных, нежели стектрейс. :)