Да сохранить. причем можно в тот же стек. Можно в регистр. Вообще это всё происходит "на лету" без операций над всей строкой. Вы же в пин-понге тоже должны как-то понимать где число закончилось, где разряды, etc.
Преобразование != расчет. Это же два разных алгоритма! в ОПН НЕТ скобок. Незачем они там. Преобразование инфиксной записи в ОПН к ОПН не имеет НИКАКОГО отношения
Толи автор перепутал алгоритмы вычисления/разбора ОПН, толи статья касается преобразования вариантов записей… Откуда-то взялись скобки в ОПН… я запутался.
В конце сравнения двух (вообще трёх) алгоритмов:
Первый (первые два) сначала преобразуют строку инфиксной нотации в постфиксную (первый алгоритм) потом её расчитывает(второй алгоритм).
Объяснение, прошу прощения, чего?
Того что функциональные не дают 100% покрытия? Так я объяснил, конвейер снижает вариативность поступающих данных (часть мутирует, часть валидируется). Функциональные тесты не выбрасывают половину Exception-ов глуша и обрабатывая их выше (в лучшем случае).
Юнит тесты сразу и точно показывают где что-то сломалось…
Есть у нас 100 модулей, каждый из которых прибавляет ко входящему параметру 1. Модули объединены в один конвейер. Покрываются одним функциональным тестом.
Правим 1 модуль теперь он добавляет 2 к параметру. Тест упал. В каком модуле произошла ошибка?
Ладно, это просто. Нашли в гите, поправили.
Два разработчика поправили по модулю. один теперь добавляет 0, второй добавляет 2. Ошибки компенсировали друг-друга. Тест пройден. Но приложение содержит ошибку. И когда эта мина подорвётся?
Во второй части своего комментария вы описываете необходимость функционального тестирования. С этим я не спорил
Даже если дампы просмотреть под лупой, то это не гарантирует покрытия всеми возможными тестами.
Эти дампы придется накатывать после каждого теста. Дороговато выходит.
Без генераторов Unit-тестирование тоже становится адом.
А в чем польза-то в заключении?
В том, что функциональные тесты не проверяют работу приложения полностью.
даже если покрывают 100%
Юнит-тестирование, на то и «Юнит». Чтобы отдельно проверить логически завершённый сегмент всевозможными данными, пройти по всем вилкам условий, выкинуть и отловить все Exception-ы.
Только после юнит-тестирования имеет смысл делать функциональные (как работает весь конвейер).
PS. Если юниттесты долгие, советую использовать заглушки модулей которые пытается вызвать тестируемая часть. Если ваш ЯП поддерживает monkey patching из коробки то задача упрощается до безобразия.
PPS. Если код плохо поддаётся тестированию — то код плохо написан
С дампами данных можно прийти в другую крайность. Синтетически всё выглядит работоспособным, а на деле падает.
А вообще у тестов должна быть своя архитектура, DRY, KISS и прочее.
Ну и разумеется Unit -> Feature -> Поведенческие.
Почему вас тогда не смущают функции? Они же вообще в префикс ной написаны: doSomeShit(a,b)
(1+2)*(3+4) — инфиксная (привычная вам)
1 2 + 3 4 + * — ОПН
1. Вход 1, стек {}, пушим в стек
2. Вход 2, стек {1}, пушим в стек
3. Вход +, стек {2,1} Берем из стека два элемента проводим операцию, возвращаем в стек.
4. Вход 3, стек {3}, пушим в стек.
5. Вход 4, стек {3,3} пушим в стек.
6. Вход +, стек {4,3,3} Берем из стека два элемента проводим операцию, возвращаем в стек.
7. Вход *, стек {7,3} Берем из стека два элемента проводим операцию, возвращаем в стек.
7. Вход пусто, Стек {21}. Конец. В стеке решение
Это цитата из алгоритма преобразования инфиксной записи в постфиксную.
потому, что вы не правильно написали… в ОПН это будет ABCD+-+
В конце сравнения двух (вообще трёх) алгоритмов:
Почему при этом строится вывод о вреде ОПН?
Это мина замедленного действия.
Только ситхи все возводят в абсолют
Объяснение, прошу прощения, чего?
Того что функциональные не дают 100% покрытия? Так я объяснил, конвейер снижает вариативность поступающих данных (часть мутирует, часть валидируется). Функциональные тесты не выбрасывают половину Exception-ов глуша и обрабатывая их выше (в лучшем случае).
Юнит тесты сразу и точно показывают где что-то сломалось…
Есть у нас 100 модулей, каждый из которых прибавляет ко входящему параметру 1. Модули объединены в один конвейер. Покрываются одним функциональным тестом.
Правим 1 модуль теперь он добавляет 2 к параметру. Тест упал. В каком модуле произошла ошибка?
Ладно, это просто. Нашли в гите, поправили.
Два разработчика поправили по модулю. один теперь добавляет 0, второй добавляет 2. Ошибки компенсировали друг-друга. Тест пройден. Но приложение содержит ошибку. И когда эта мина подорвётся?
Во второй части своего комментария вы описываете необходимость функционального тестирования. С этим я не спорил
гоблинбанк с большей вероятностью просто пошлёт.*кроме блокчейна, он не помогает.
Эти дампы придется накатывать после каждого теста. Дороговато выходит.
Без генераторов Unit-тестирование тоже становится адом.
А в чем польза-то в заключении?
Юнит-тестирование, на то и «Юнит». Чтобы отдельно проверить логически завершённый сегмент всевозможными данными, пройти по всем вилкам условий, выкинуть и отловить все Exception-ы.
Только после юнит-тестирования имеет смысл делать функциональные (как работает весь конвейер).
PS. Если юниттесты долгие, советую использовать заглушки модулей которые пытается вызвать тестируемая часть. Если ваш ЯП поддерживает monkey patching из коробки то задача упрощается до безобразия.
PPS. Если код плохо поддаётся тестированию — то код плохо написан
Главная ошибка
А вообще у тестов должна быть своя архитектура, DRY, KISS и прочее.
Ну и разумеется Unit -> Feature -> Поведенческие.