через тсп + Pipe обработку но начал на юнит тестах слать мусорные данные чтоб отличались от формата который парсер умеет обабатывать и так как я в пайп вовзращают что не смогло обработаться ...сами понимаете получил дофига проблема с выделением памяти. и все изза логики что пытался докачать ожидаемое сообщение.. получается проще всего мне тогда сделать некий лимит буфера папйпа чтоб скинуть его если до этого там так и не появилось что то по ожидаемому формату или есть более изысканое решение в таких случаях?
Звучит как неправильный подход. Если ЮНИТ тестируется парсер, то зачем выстраивать всю цепочку, аж с пайпами и TCP? Почему не взять парсер и не запихивать в него данные напрямую?
Возможно под юнит тестами понимаются просто тесты на nunit/xunit/msunit)
в юните нет всей цепочки. тут косяк мой не так описал. но цепочку я протестировал руками с эмуляций мусора в канале
Ну... Может быть =) Но тестировать парсер поднятием TCP канала чтобы туда пихать данные - это как-то излишне всё равно, имхо. Ну, либо в парсер протекло такое понятие как "TCP"
да не суть же) вопрос как понять что треш и в какой момент бы скинуть буфер что не ожидать дальше
Никак? =) Если парсер не может работать потоково, и ему нужно полное сообщение, то надо ждать это самое полное сообщение. Когда остановиться - на вкус и цвет, можно таймаут, можно лимит на размер запроса и т.д. Я же не знаю что именно вам подойдёт
Обсуждают сегодня