Здравствуйте, Doom100500, Вы писали:
D>Мою ошибку в твоём кривом дизайне? D>Ты победил.
Все что ты говоришь — это относится к однопоточному приложению. Видел ли когда-нибудь тесты, направленные именно на проверку в многопотоке? Только честно.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Doom100500, Вы писали:
D>>Мою ошибку в твоём кривом дизайне? D>>Ты победил.
S>Все что ты говоришь — это относится к однопоточному приложению. Видел ли когда-нибудь тесты, направленные именно на проверку в многопотоке? Только честно.
Я их писал на нескольких языках.
Тебе надо проверять ожидаемое состояние с текущим.
Тебе надо знать что будет система дедать и как обрабатывать систуации когда это не согласуется (это то, чего в твоём дизаине нет в принципе).
Ты не можешь тестами задетектить дедлок, но ты можешь сделать дизаин таким, чтобы ты смог определить такую ситуацию и принать соответствующие меры (вот это ты в тестах и проверяешь).
Сделать ты это можешь, если у тебя всегда есть хендлы/указатели/ референсы на что-то, что во что у тебя обёрнуты потоки. Синхронизация должна быть с таймаутами (опять что-то, что можно протестировать), а это уже не просто lock{} из helloword и chatgpt, а что-то с контролем времени. Тебе нужно знать как очистить систему при возникновении ситуации, когда ты решаешь прибить сущетвующие задачи с соответствуйющим фидбеком вызывающей стороне, чтобы она также могла обработать эту ситуацию. А для этого тебе нуже вменяемый протокол обмена информацией между твоими потоками. Всего этого у тебя нет.
Весь это обвес и проверяешь в тестах мокая то один интерфейс то другой, дабы создать валидное/не валидное состояние.
Здравствуйте, Doom100500, Вы писали:
D>Сделать ты это можешь, если у тебя всегда есть хендлы/указатели/ референсы на что-то, что во что у тебя обёрнуты потоки. Синхронизация должна быть с таймаутами (опять что-то, что можно протестировать), а это уже не просто lock{} из helloword и chatgpt, а что-то с контролем времени. Тебе нужно знать как очистить систему при возникновении ситуации, когда ты решаешь прибить сущетвующие задачи с соответствуйющим фидбеком вызывающей стороне, чтобы она также могла обработать эту ситуацию. А для этого тебе нуже вменяемый протокол обмена информацией между твоими потоками. Всего этого у тебя нет.
Для конкретного обсуждения нужно уточнить пример — указать язык/платформу. Потому что в некоторых случаях все исполняется вообще в одном потоке — что даже синхронизация не нужна (Future может вызывать системный вызов в другом потоке, но потом все-равно вернет управление в тот же поток). Но при этом все-равно возможна проблема с очередностью вызовов.
Если готовы не хорохориться перед девками а серьезно обсуждать — давай приведу пример на C#, к примеру.
Здравствуйте, Shmj, Вы писали:
S>Если готовы не хорохориться перед девками а серьезно обсуждать — давай приведу пример на C#, к примеру.
Ты бы не обещал, а делал. Хочешь показать код — показывай. Хочешь оставаться в КСВ (а иначе зачем это всё тут) — оставайся.
Хорохоришься здесь ты защищая своё (списанное скорре всего) кривое решение (как впрочем всегда).
Я уже видел как тебя непрошибаемым называют. А сейчас увидел почему.
Здравствуйте, Doom100500, Вы писали:
D>Ты бы не обещал, а делал. Хочешь показать код — показывай. Хочешь оставаться в КСВ (а иначе зачем это всё тут) — оставайся. D>Хорохоришься здесь ты защищая своё (списанное скорре всего) кривое решение (как впрочем всегда).
Дело в том что мой конкретный код — под Flutter. А это скорее язык мало распространен. Можно перевести на C#, но проблема в том что с потоками эти платформы работают совершенно по-разному. Хотя кое какие идеи сохраняются.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Doom100500, Вы писали:
D>>Ты бы не обещал, а делал. Хочешь показать код — показывай. Хочешь оставаться в КСВ (а иначе зачем это всё тут) — оставайся. D>>Хорохоришься здесь ты защищая своё (списанное скорре всего) кривое решение (как впрочем всегда).
S>Дело в том что мой конкретный код — под Flutter. А это скорее язык мало распространен. Можно перевести на C#, но проблема в том что с потоками эти платформы работают совершенно по-разному. Хотя кое какие идеи сохраняются.
Я немного с ним игрался, если что. Код понять смогу, но в доки по стандартным либам я сегодня не полезу.
Если хочешь что-то делать на новом языке/технологии — то, возможно, чат-бот и даст кое-какое представление, но для построения грамотной архитектуры желательно посвятить время на изучение нюансов, которых в helloword's просто нет ( а на таких примерах chat bot, в основном, и учится — это всё-же на главных страницах проектов — легко для парсинга).
С другой стороны разные пошаговые мануалы, полностью посвящённые отдельному нюансу, часто скрыты за регистрацией, поэтому таких примеров для обучения чат-боту не дали.
Серьёзно — это не долго изучить (проработать) нюансы , просто требует увлечённости и сосредоточения.
1. Сделать спец-интерфейс вида interface DebugSynchronization { void wait(String point); }.
2. В реализацию класса пробросить этот интерфейс и во всех интересующих точках вызывать debugSynchronization.wait("pointname").
3. В продакшне использовать реализацию с пустым методом.
4. Для тестов использовать специальную реализацию, которой можно управлять. Т.е. запускаем интересующий нас метод в отдельном потоке, а из потока-теста вызываем что-то вроде waitForArrival("pointname"), resume("pointname"). Эти методы останавливают вызывающий поток, пока целевой поток не дойдёт до указанной точки (в этот момент тестируемый поток останавливается в wait) или продолжают выполнение тестируемого потока, который остановился в указанной точке.
Собственно таким образом внутри тестов можно смоделировать любую последовательность выполнения участков кода, имитируя переключение потоков "вручную". При этом тест будет полностью детерминированным.
Наверняка я не первый это придумал и такое уже есть в готовом виде.
Тут, конечно, не очень красиво получается, что в обычный код просочился тестовый. Ну лучше варианта не знаю.
