fez писал(а) 11. Мая 2010 :: 11:51:

Прежде всего, считаю необходимым уточнить терминологию. Предлагаю пользоваться следующей классификацией видов и уровней тестирования, которая кажется  мне наиболее логически понятной:
http://protesting.ru/testing/testtypes.html
http://protesting.ru/testing/testlevels.html.

Т.е., в данной ветке мы рассматриваем только функциональный вид тестирования. Речь зашла о модульном (юнит) уровне тестирования. Так вот юниттестирование на 1С невозможно по причине того, что платформа не поддерживает механизм интерфейсов, соответственно далеко не всегда возможно в юнит передать мок-объект. Это приводит к тому, что мы, пытаясь протестировать, скажем, объект-документ, тестируем еще и код объектов, навязанных платформой. Например, код в модуле набора записей. Понятно, что в случаях, где платформа не ограничивает тип объектов, мы имеем возможность использовать моки. Но, далеко не всегда. Поэтому, если говорить об уровне тестирования на платформе 1С, имеет смысл говорить о системном уровне тестирования.

Цитата:

Действительно, это другой вопрос. И его можно было бы обсудить в отдельной ветке. В смысле не кривизну типовых, а приемы, повышающие тестопригодность конфигурации.

Цитата:

Во! Это уже по-существу! Как ты себе представляешь весь процесс при таком подходе?

Палыч писал(а) 12. Мая 2010 :: 07:10:

http://www.1cpp.ru/forum/YaBB.pl?num=1273770703

fez писал(а) 13. Мая 2010 :: 17:09:


Мне тоже непонятно откуда у тебя взялся такой вывод. 
Моя мысль была о том, что юниттестирование на платформе 1С невозможно в общем случае. Т.е., не любой модуль возможно протестировать на уровне модуля. Что, впрочем, не исключает наличия частных случаев, о которых ты пишешь и о которых  я, кстати, тоже сделал оговорку. Об этом я написал на первой странице не ради спора о полупустоте/полуполноте стакана, а ради того, чтобы подчеркнуть, что тестирование на платформе 1С требует техник не только и не столько юнит-, сколько системного тестирования. В частности, генерации данных в БД.

Палыч писал(а) 14. Мая 2010 :: 06:54:

Да. Есть правда у такого подхода проблема. Когда тебе например нужно протестировать, что в определенной ситуации созданный тобой документ не запишется (и потом нужно проверить что-нибудь еще) - вот тут приходит птичка обломинго.

fez писал(а) 14. Мая 2010 :: 08:12:

Как это при чем?! На 1С, в отличие от универсальных средств разработки, насколько бы конфига ни была самописной, не удастся заменить, скажем набор набор записей регистра в объекте документа. А проблемы тестирования разработок на взрослых языках меня, на данный момент, мало волнуют.

Цитата:

Цитата:

[делаю вид, что не заметил эти тезисы] 

Цитата:

Ты уже, наверно, догадался, что я отвечу: скажу тебе больше, конечному потребителю платформы 1С  никакое тестирование вобще не нужно! 

И вобще, мне не совсем понятно, какую мысль ты хочешь донести? Что юниттестирование на 1С имеет право на жизнь? Дык я и не возражаю! 
Правда, при этом, возникает вопрос как ты тестируешь обеспечиваешь  (или предполагаешь в будущем) качество элементов конфигурации к которым платформа не дает доступа на уровне юнита? Тот же пресловутый документ, например?

Палыч писал(а) 14. Мая 2010 :: 09:06:

Не думал пока. Придумаю что-нибудь, когда дело дойдет

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

fez писал(а) 14. Мая 2010 :: 09:24:

Например, справочники номенклатура, организации, контрагенты и т.п. Ты их включаешь в базовый набор?