Чую, в проекте будет под сотню POU. Неплохо бы покрыть это юнит-тестами. Как это тут вообще делают?
Собрать проект в библиотеку, и написать к каждому POU по тесту?
Вид для печати
Чую, в проекте будет под сотню POU. Неплохо бы покрыть это юнит-тестами. Как это тут вообще делают?
Собрать проект в библиотеку, и написать к каждому POU по тесту?
Для большого проекта лучше написать программные симуляторы (математическую модель) реального оборудования (датчиков, насосов, приводов и т. д.) и к ним подключить свои POU, в визуализации Кодесис вывести показания датчиков и других сигналов, которые надо тестировать. Некоторые делают это в отдельном ПЛК.
Как придеццаЦитата:
Как это тут вообще делают?
Это, в общем-то, и есть юнит-тесты. Жаль, что нет типового решения.Цитата:
Сообщение от amn
Визуализация в таком деле не очень хороший подход. Автоматические тесты всегда предпочтительнее -- меньше работы, меньше ошибок, не лень гонять после внесения изменеий. Если на входе -- мат. модель, то и проверять программно без проблем должно быть.
Для типовых задач ? Дык они ж типовые и уже давно все проверено.Цитата:
Жаль, что нет типового решения.
Конечно. Сначала пишем нестандартную программу. После для нее нестандартный автотест. И все легко автоматически тестируем.Цитата:
Автоматические тесты всегда предпочтительнее
Да не, тестового фрейворка. Ну типа, чтобы все тесты однотипно гонялись и рапортовали ошибками, и все чтобы оптом прогнать, да ответ вывалить в xml-html-типатого.Цитата:
Сообщение от Валенок
Ну можно и с обратной стороны посмотреть. Test driven development типа.Цитата:
Конечно. Сначала пишем нестандартную программу. После для нее нестандартный автотест. И все легко автоматически тестируем.
Если ты понимаешь, что должен делать твой модуль, ты можешь описать это. Если это изложено, то можно на каждую фичу-фичульку написать тест. Если всё покрыто тестами на 100%, то программа, которая все тесты пройдет, автоматически будет делать то, что тебе нужно ))
Есть. Емуляция. Она может просто засыпать описанием ошибок))Цитата:
Да не, тестового фрейворка...
Если я понимаю что должен делать модуль, я пишу что он должен делать. Или Вы пишете нечто, после ломаете мозг на тем как проверить нечто. Может сразу поломать мозг на тем чтобы делало что нужно если "ты понимаешь, что должен делать"Цитата:
Если ты понимаешь, что должен делать твой модуль
Но для этого предварительно нужно протестировать эти тесты)Цитата:
Если всё покрыто тестами на 100%..
Вы путаете неработающий модель и работающий неправильно.Цитата:
Сообщение от Валенок
вы пишете без ошибок? Это бывает, но это редкое качество.Цитата:
Если я понимаю что должен делать модуль, я пишу что он должен делать.
на самом деле достаточно разбора при падении.Цитата:
Но для этого предварительно нужно протестировать эти тесты)
Я тоже не очень верю в хардкорный подход, тесты вперед кода требуют слишком хорошего ТЗ. Но когда ближе к концу начинается "тут подпилить, там перекрасить" -- на этом этапе тесты облегчают. Потому что если случайно поломал -- это быстро всплывет.
Конечно, тем, кто сразу пишет без ошибок - это всё не надо. Но таких немного, на все проекты не хватает.
так а Вы не пишите весь проект целиком, ни кто не запрещает тестить отдельно взятое ПОУ, подавая на него различные генераторы сигналов и записывая лог состояний выходовЦитата:
Сообщение от rapucha
Конечно. Но когда тест гоняется автоматом после каждого изменения и не требует ручной сверки результатов -- это чрезвычайно удобно.Цитата:
Сообщение от capzap
именно про это я и говорю, остается определиться что понимается под ручной сверкой, если математический результат чему равно дважды два и Вы точно знаете какая константа будет на выходе это одно, а если мои модели изменяют температуру, уровень в зависимости от ИМ и наступающие события происходят когда происходят, кроме как "ручного" наблюдения за результатом быть не можетЦитата:
Сообщение от rapucha
Я пока не понял, умееет ли симулятор симулировать значения на входах. Если умеет -- то, казалось бы, можно без ручного наблюдения.Цитата:
Сообщение от capzap
Начали менять параметр, ждете результат, сверяете с нужным. Если тестируется отдельный модуль, а не вся логика программы в целом -- то будет набор независимых проверок.
Даже с реальной температурой так можно, но это уж сильно заморочиться надо.
это, конечно, не гарантия того что всё в целом будет работать правильно. Но хорошая страховка.