V7: Автоматическое тестирование функционала конфигураций. FuncTest-0.10.2 #26822

- Исправлена ошибка: Не работало условие "Тест_НеУчитыватьПробелыВСтроках". - Восстановлены классы, необходимые для работы конвертора тестов. - Добавлена возможность получения всех атрибутов формы тестируемого отчета. - Исправлена ошибка: При создании нового теста ожидания копировались от предыдущего теста. - Добавлена возможность переименования колонок в таблице ожиданий. - Добавлена возможность менять колонки местами. . /

Да... Цитата:    7. Что сделано. История версий. (Updated 25/01/05)       11. Скачать. Последняя версия FuncTest - 0.10.2 (Updated 25/01/05) КонецЦитаты Что-то там не то со временем и датой...

Мда. Спасибо. Поправлю.

fez, насколько я понимаю, твой комплекс, да и вообще методика test-first работает в случае, когда решение задачи известно наперед. а что делать в случае, когда решение не известно, либо оно не однозначно, НО известен, грубо говоря, "алгоритм" решения задачи?

Свобода творчества в 1С:Предприятии 7.7 зажата в узкие рамки. Работа Федора в этом отношении уже попытка выйти за них. Асмодей, ответ на : работать с более развитой системой автоматизации разработки ПО.

Если ты в принципе не знаешь решения своей задачи - как ты сможешь проверить: правильно ли ты реализовал свой алгоритм, или где-то ошибся?

об этом и речь... допустим, идет постановка задачи (грубо): "тут играем, тут не играем, тут рыбу заворачивали, но нужем отчет, и чтобы данные верные". анализ результата (т.е. отчета) происходит по принципу: "ну вроде похоже на правду". через неделю: "блин, а вот этот косяк не учли совсем. все переделать". вот как-то хочется от такого уйти... к сожалению, ограничены мы все этими самыми двумя платформами, и не по своей воле. ЗЫ: прочитал (или прочел?) недавно книгу "Путь камикадзе". там одна из рекомендаций - "если вам неудобно работать со средой, меняйте к черту среду"... звучит заманчиво и забавно >;))

"Тут играем" - описываем в виде тестов. "Тут не играем" - описываем в виде тестов. "Тут рыбу заворачивали" - описываем в виде тестов. "Но нужен отчет" - После выполнения первых трех пунктов у нас уже есть некие тестовые данные, для которых вроде бы должно быть понятно - какой должен быть отчет. Описываем отчет в виде тестов. "Через неделю, блин, а вот этот косяк..." - косяк описываем в виде тестов. Обычная задача, для которой известно, что нынешняя постановка - временная. Это не страшно, таких задач на самом деле - большинство. Тем не менее для таких задач известно временное решение - и именно его и нужно реализовывать. В том числе и в тестах.

fez, тебе по это разработке нужно обширную статью написать (методичку), а то мало что понятно нафина это нужно. Чтобы поюзать - нужен интерес, чтобы был интерес - нужно подробно и доходчиво описать разработку.

Это будет набор лозунгов типа "Вы хотите, чтобы разработка Вашего ПО была прогнозируемой, а результаты - предсказуемыми и постоянными? Тогда мы идем к Вам". Или же это будет пересказ содержимого книг и сайтов, посвященных XP и TDD. Ни тем, ни другим мне заниматься не хочется.

9. Допустим, sql.ru  - там тоже во многом пересказ, но пересказ применительно к конкретной тематике лишь увеличивает ценность пересказанного.

Хорошо, скажу так. Ни тем ни другим мне _сейчас_ не хочется заниматься. Если я захочу популяризовать Фанктест - очевидно, я займусь этим.

fez Давай я попробую написать методичку.

без документации разработка "для себя" останется "разработкой для себя". просто для _эффективного_ использования твоей разработки тех примеров, что есть на сайте явно не достаточно. XP и TDD - оч.хорошие абревиатуры, но применительно к 1С? ибо большая часть доступной документации ориентирована в первую очередь на ООП-языки (причем, основной упор делается на С++ и java,  встречаются материалы по Delphi и VB, и всякой экзотике, вроде SmallTalk), каковым v77, к сожалению, не является (даже 1С++ чаще всего дело не спасает)

Давай. Попробуй абстрагироваться от классов и методов. У тебя есть программа (из набора маленьких программ), которая получает одни данные и возвращает другие. Действие маленькой программы с данными мы и тестируем. Для ООП языков такой программкой является абстрактный метод абстрактного класса. Для v7 такой программкой служит или некий отчет, или метод Провести класса "Документ".

абстрагируюсь: у меня есть "программка", которая получает ссылку на объект (допустим, прДок) и 1) проверяет допустимость входных объектов (прим: ПустоеЗначение(прДок)=1) 2) анализирует состояние полученных объектов (прим: прДок.ВидОперации=...) 3) анализирует окружение объекта (состояние связанных объектов, объектов системы, расчетных значений и т.п.) 4) если состояние объекта и его окружения соответствует некоторому предопределенному состоянию, то создается некий новый объект с заданными свойствами (глПроводка и т.п.) {пункт 4 повторяется для других состояний} 5) возможно, "программка" возвращает ссылки на созданные объекты. напрашивается тест: закинуть в "программку" объекты в различных состояниях {их много}, смоделировать состояние системы в целом (итоги, обороты и т.д.) {их еще больше}, проанализировать полученные результаты {ну их тоже не мало} даже (допустим) если удастся описать "область определения" и "область допустимых значений" этой "программки", то ожидать, что при том или ином состоянии системы в целом результат будет тот же, а не иной мы достоверно сказать не сможем.

Несомненно. Однако мы сможем утверждать, что в смоделированных нами состояниях программка работать будет именно так, как нам хочется. А это уже немало. В любом случае, запустить тесты, которые помогут проверить часть возможных ситуаций, много лучше, чем не запускать никаких тестов вообще, аргументируя невозможностью полной проверки.

какой ленивый народ, однако

17. Ты про feza?

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

я про народ, который ленится почитать немного, чтобы представлять назначение и методику использования авт. тестирования. ты им сделай, разжуй да куда надо положи...

а ты не согласен с тем, что для того, чтобы _эффективно_ использовать какой-то инструмент, нужно сначала разобраться в возможностях и особенностях этого инструмента?

20. Это все равно что сделать программу и сказать юзерам, чтоб изучали сами. Зачем я буду тратить время на изучение того, что мне возможно не нужно? Обычно сначала читают о продукте (реклама), а потом уже юзают (покупают).

Если ты найдешь пример, который докажет, что программка не работает - этот пример - отличный кандидат для нового тестового случая. ФанкТест он все же не для обычного юзера. И даже не для обычного программиста 1С. Он в первую очередь для программиста, который хочет применять XP и TDD в 1С, но не знает, как именно это делать. То есть предполагается, что человек знаком и согласен с XP и с TDD. И знакомить и агитировать за XP и TDD я не буду ровно по тем же причинам, по каким я не буду учить программировать на 1С. Ибо для этого есть другие ресурсы.

вот именно, если найдешь. проблема в том, что я не могу в 1С смоделировать "окружение" или, если хотите, "контекст" теста. это не касается фанктеста, это замечание (или сожаление) вообще.

А что мешает моделировать окружение?

ну вот, допустим я хочу попробовать провести _один и тот же_ документ в разном "окружении". ну хотя бы с разными итогами по счетам. раз 20. и посмотреть на результаты.

Создай несколько копий своего документа. Помести каждую копию - в свое окружение.

т.е. сделай 20 тестовых баз, сформируй там какие-то итоги и пускай тест? забавно.

Зачем? У тебя ведь документ критичен не ко всем итогам, а с каким-то разделителем. Контрагент, Товар или Фирма. Вот пусть документы и различаются этими разделителями.

хорошо. пример: разнесение авансов. или расчет суммовых разниц. т.е. поведение (и проведение) документа зависит от предыстории. как смоделировать историю?

хотя, я уже предвижу ответ: заведи 20 контрагентов и для каждого создай свою историю. и сделай 20 документов.

найди в интернете программку "большая зеленая кнопка" и жми на нее. она будет делать за тебя твою работу.

не смешно.

по теме - вот пришла в голову мысль - сделать на 1С++ некий класс (или несколько классов) для моделирования контекста. т.е. чтобы при тестировании оно выдавало наперед заданные значения, а при работе - обращалось к "среде". но только придется больше половины функционала 1С туда загнать и модули писать с учетом этого класса.

ну хоть чуточку почитай. например тут , а потом тут yandex.ru.

Если для полного моделирования тестовой ситуации недостаточно одного документа - очевидно нужно завести несколько документов. Тесты для таких документов, объединенных одной тестовой ситуацией, лично я имею обыкновение помещать в одну подпапочку - так нагляднее. Ну вот видишь, ты сам все понял. Добавлю только одно: в моей практике мне ни разу не пришлось создавать 20 различных историй для одного типа документов. Обычно все заканчивается где-то на второй-четвертой, максимум - седьмой истории.

ИМХО, не лучшая статья. тут гораздо приятней и понятней. >;))

Судя по интонации в - тебе не очень нравится данный способ. Не можешь ли пояснить - чем именно?

да как-то у меня ручное создание "обстановки" не вяжется с автоматическим тестированием. изменил структуру - правь все документы вместе с "обстановкой" - некузяво...

а если еще и несколько человек работает...

Извини, не понял: структуру чего ты поменял? И почему потом нужно менять документы? Если мы говорим о структуре БД, то по моему опыту - менять приходится только ожидания тестов. И в очень незначительно количестве. . Вообще, странно мне все это. Вот romix в согласен глазками искать различия, и считает, что это вполне так себе автоматическое тестирование. Ты же наоборот: хочешь отдать компьютеру в общем-то неавтоматизируемую работу. Ибо если после изменения дизайна системы сломалось 20 старых тестов - то никогда нельзя заранее сказать: это следствие ошибки программиста, или это несоответствие старых тестов новым требованиям. Нужно каждый случай внимательно рассматривать, и принимать решение по каждому в отдельности.

я хочу 1 раз описать объект теста, "контекст" теста и ожидаемый результат теста. во-первых, тогда я смогу вставлять разные объекты (одного класса) в разные контексты, при этом анализируя ожидаемые результаты. во-вторых, при изменении чего-либо, мне не придется каждый тест выстраивать заново, достаточно внести изменения, грубо говоря, "в-то-место", которое подверглось изменениям.

Я не понял, а что из вышеперечисленного не делает FuncTest? В чем трудности? . PS. У меня уже начинает закрадываться мысль, что ты не знаешь, что 1С умеет копировать документы :)

Компьютерные программы - сплошное надувательство

описание контектса не делает (или я не нашел, как это сделать). к фанктесту у меня претензий нет, я пытаюсь идеологию развить.

Ожидания ведь не всегда легче ручками вбить, чем получить один раз программно, а потом скинуть в текстовичок в качестве эталона, после чего сверять? Программа сразу покажет изменения, что надо проверить/утвердить в качестве следующего эталона. А вручную, предварительно, забивать движения, мне кажется, как-то лениво... Да и в 1С (к сожалению) нету места, куда бы их можно было вбить. Кстати, может им в 1С идею такую послать, как думаешь?

вот развитие идеи в 1. создаем абстрактную фабрику. 2. для создания объектов вместо СоздатьОбъект используем эту фабрику 3. по-умолчанию фабрика дублирует работу СоздатьОбъект 4. тест подменяет фабрику, которая вместо некоторых, _заранее определенных_ в тесте объектов, возвращает их заместителей, у которых значения свойств и методов переопределено описанием контекста (для неопределенных в тесте объектов можем вернуть стандартные, либо сообщать, что объект не определен) 5. в результате можем добиться эффекта "погружения" тестируемого объекта в предопределенный контекст.

49. Есть аргументы?

уже и вопросов нет >;))

Ну это больше подходит уже к юниттестированию. Кстати, я сегодня обновил свои наработки по юниттестированию под 1С++. Получилось довольно забавно.

согласен. но можно же и заказчику показать: вот, допустим у нас такие итоги до проведения и вот такие у нас проводки получились.

Заказчику будет нагладнее, если ты смоделируешь эти самые итоги не классом 1С++, в котором он ни черта не понимает, а знакомым ему документом. . PS. Он даже может не знать, что такое итоги. Он знает одно: если оплата до отгрузки - одни проводки, если оплата впереди - другие проводки. Все.

это вопрос интерфейса и терминологии. дай человеку интерфейс "а-ля ОСВ" и скажи "тут мы _зададим_ оборотку до проведения документа".

Мысль хорошая. Мысль просто супер. Но в одной оборотке многого не видно - к примеру в оборотке невозможно указать, в какой последовательности погашать документы долга. Так что в реальности нужно много таких интерфейсов "а-ля разнообразные отчеты". А в идеале нужен быстрый и удобный способ создания произвольного количества таких интерфейсов. . Так вот: имея в руках универсальный интерфейс документа - лично я не буду заморачиваться на реализации новых универсальных интерфейсов. Ибо мне кажется, что овчинка выделки не стоит. . Я был бы рад ошибиться, ибо мысль действительно супер.

скорее всего в любом случае придется применять принцип "сочетания разумного с полезным". в предельном случае этой фабрикой можно вообще перекрыть весь функционал 1С (типа сделать свои проводки, БухИтоги и прочее). но скорее всего практическая ценность подобной работы сомнительна...

Я определяю для себя разумность одним простым способом. Стал бы я на этом заморачиваться, или не стал бы. В этом конкретном случае - не стал бы. Несмотря на очевидную полезность.