А как вы тестируете программы на CoDeSyS?

[rapucha]

Чую, в проекте будет под сотню POU. Неплохо бы покрыть это юнит-тестами. Как это тут вообще делают?
Собрать проект в библиотеку, и написать к каждому POU по тесту?

[amn]

Для большого проекта лучше написать программные симуляторы (математическую модель) реального оборудования (датчиков, насосов, приводов и т. д.) и к ним подключить свои POU, в визуализации Кодесис вывести показания датчиков и других сигналов, которые надо тестировать. Некоторые делают это в отдельном ПЛК.

[Валенок]

Как это тут вообще делают?

Как придецца

[rapucha]

Для большого проекта лучше написать программные симуляторы (математическую модель) реального оборудования (датчиков, насосов, приводов и т. д.) и к ним подключить свои POU, в визуализации Кодесис вывести показания датчиков и других сигналов, которые надо тестировать. Некоторые делают это в отдельном ПЛК.

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

[Валенок]

Жаль, что нет типового решения.

Для типовых задач ? Дык они ж типовые и уже давно все проверено.

Автоматические тесты всегда предпочтительнее

Конечно. Сначала пишем нестандартную программу. После для нее нестандартный автотест. И все легко автоматически тестируем.

[rapucha]

Для типовых задач ? Дык они ж типовые и уже давно все проверено.

Да не, тестового фрейворка. Ну типа, чтобы все тесты однотипно гонялись и рапортовали ошибками, и все чтобы оптом прогнать, да ответ вывалить в xml-html-типатого.

Конечно. Сначала пишем нестандартную программу. После для нее нестандартный автотест. И все легко автоматически тестируем.

Ну можно и с обратной стороны посмотреть. Test driven development типа.

Если ты понимаешь, что должен делать твой модуль, ты можешь описать это. Если это изложено, то можно на каждую фичу-фичульку написать тест. Если всё покрыто тестами на 100%, то программа, которая все тесты пройдет, автоматически будет делать то, что тебе нужно ))

[Валенок]

Да не, тестового фрейворка...

Есть. Емуляция. Она может просто засыпать описанием ошибок))

Если ты понимаешь, что должен делать твой модуль

Если я понимаю что должен делать модуль, я пишу что он должен делать. Или Вы пишете нечто, после ломаете мозг на тем как проверить нечто. Может сразу поломать мозг на тем чтобы делало что нужно если "ты понимаешь, что должен делать"

Если всё покрыто тестами на 100%..

Но для этого предварительно нужно протестировать эти тесты)

[rapucha]

Есть. Емуляция. Она может просто засыпать описанием ошибок))

Вы путаете неработающий модель и работающий неправильно.

Если я понимаю что должен делать модуль, я пишу что он должен делать.

вы пишете без ошибок? Это бывает, но это редкое качество.

Но для этого предварительно нужно протестировать эти тесты)

на самом деле достаточно разбора при падении.

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

Конечно, тем, кто сразу пишет без ошибок - это всё не надо. Но таких немного, на все проекты не хватает.

[capzap]

Конечно, тем, кто сразу пишет без ошибок - это всё не надо. Но таких немного, на все проекты не хватает.

так а Вы не пишите весь проект целиком, ни кто не запрещает тестить отдельно взятое ПОУ, подавая на него различные генераторы сигналов и записывая лог состояний выходов

[rapucha]

так а Вы не пишите весь проект целиком, ни кто не запрещает тестить отдельно взятое ПОУ, подавая на него различные генераторы сигналов и записывая лог состояний выходов

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