ИЧ
Если их сложно поддерживать, знать архитектура плохо тестируемая. Значит у всего проекта проблемы в целом, и с тестированием в том числе
Да, микросервисы которые мы заслужили
Size: a a a
2020 April 02
p
Да, микросервисы которые мы заслужили
Для микросервиса интеграционный тест это отправка по сети запроса в микросервис, и проверка чтобы возвращаемый результат оказался ожидаевм
p
Это вполне легко реализуется
ИЧ
Для микросервиса интеграционный тест это отправка по сети запроса в микросервис, и проверка чтобы возвращаемый результат оказался ожидаевм
Это юниттесты.
p
Это интеграционный тест
ИЧ
Это интеграционный тест
Если все замокано, то нет
p
Что замокано? Просто ты обращаешься к микросервису будто в реальном приложении
p
А он там пусть себе в бд ходит
DS
А какие варианты есть. Не представляю как можно развивать проект без тестов.
Я вот видел ощутимое число проектов на статически типизированных языках за время своей карьеры, которые жили без тестов очень даже успешно.
Причем, по моему опыту, количество дефектов с наличием тестов не особо коррелировало.
Причем, по моему опыту, количество дефектов с наличием тестов не особо коррелировало.
ИЧ
А он там пусть себе в бд ходит
А он ходит в другие микросервисы
ИЧ
Я вот видел ощутимое число проектов на статически типизированных языках за время своей карьеры, которые жили без тестов очень даже успешно.
Причем, по моему опыту, количество дефектов с наличием тестов не особо коррелировало.
Причем, по моему опыту, количество дефектов с наличием тестов не особо коррелировало.
Думаю зависит от размера команды
E
тесты-шместы... юзеры всё протестируют!
E
вот взять язык Аду и его тулзы — вроде есть тесты, а толку? багов полно, хоть и позиционируется эта Ада как надёжный язык для критичных применений...
E
зато практически нет юзеров, вот и кишит ада-инфраструктура багами
VM
В Ada есть и Ada SPARK.
Т.е. "доказательство правильности прграмм".
(
И "пример успеха":
линия метро в Париже.
Первая и последняя версия ПО.
Многое, правда, на (?)Safe Modula-2.
И это до SPARK.
)
Т.е. "доказательство правильности прграмм".
(
И "пример успеха":
линия метро в Париже.
Первая и последняя версия ПО.
Многое, правда, на (?)Safe Modula-2.
И это до SPARK.
)
M
Eugene
вот взять язык Аду и его тулзы — вроде есть тесты, а толку? багов полно, хоть и позиционируется эта Ада как надёжный язык для критичных применений...
Вот значит почему боинги падают 🤔
RS
https://tjournal.ru/p/aircraft-software - "За работу того же «Боинга-787» в общей сложности отвечают более 14 миллионов строк кода... Одним из основных языков, на котором пишется код для гражданской авиации, является известный любому программисту C/С++. Второй важный для отрасли язык — разработанный ещё в конце 70-х годов Ada."
МБ
Eugene
зато практически нет юзеров, вот и кишит ада-инфраструктура багами
Не в этом дело. Вот для корректности простого градиентного спуска требуется около 100 аксиом и около 10 тысяч строк доказательств на вызывающем сомнения Lean. На Coq не известно, сколько всего потребуется.
Самолётная динамика на несколько порядков сложнее, там есть железо, которое надо аксиоматизировать, и ошибок в этот весь процесс можно внести уйму даже если сами инструменты идеальны, что не так, даже в случае с Coq, который тестируют интенсивнее всего.
Инженеры, в принципе, всегда учитывают, что у любой физической системы есть MTBF, ломается всё, всё нужно подстраховывать, чтобы снижать вероятность отказа.
Но в случае программных систем почему-то есть странная вера в то, что возможно сделать идеально корректно.
Олдскульные инженеры жалуются, что в современных самолётах даже нет прямой физической связи штурвалов с рулями самолёта. И если электроника отказывает, смолёт превращается в неуправляемый гроб.
В некоторых автомобилях та же фигня: руль слишком маленький, чтобы при отказе усилителя можно было управлять машиной.
Откуда берётся вера в непогрешимость ПО у ведущих инженеров - вопрос очень интересный.
Самолётная динамика на несколько порядков сложнее, там есть железо, которое надо аксиоматизировать, и ошибок в этот весь процесс можно внести уйму даже если сами инструменты идеальны, что не так, даже в случае с Coq, который тестируют интенсивнее всего.
Инженеры, в принципе, всегда учитывают, что у любой физической системы есть MTBF, ломается всё, всё нужно подстраховывать, чтобы снижать вероятность отказа.
Но в случае программных систем почему-то есть странная вера в то, что возможно сделать идеально корректно.
Олдскульные инженеры жалуются, что в современных самолётах даже нет прямой физической связи штурвалов с рулями самолёта. И если электроника отказывает, смолёт превращается в неуправляемый гроб.
В некоторых автомобилях та же фигня: руль слишком маленький, чтобы при отказе усилителя можно было управлять машиной.
Откуда берётся вера в непогрешимость ПО у ведущих инженеров - вопрос очень интересный.
D
Не в этом дело. Вот для корректности простого градиентного спуска требуется около 100 аксиом и около 10 тысяч строк доказательств на вызывающем сомнения Lean. На Coq не известно, сколько всего потребуется.
Самолётная динамика на несколько порядков сложнее, там есть железо, которое надо аксиоматизировать, и ошибок в этот весь процесс можно внести уйму даже если сами инструменты идеальны, что не так, даже в случае с Coq, который тестируют интенсивнее всего.
Инженеры, в принципе, всегда учитывают, что у любой физической системы есть MTBF, ломается всё, всё нужно подстраховывать, чтобы снижать вероятность отказа.
Но в случае программных систем почему-то есть странная вера в то, что возможно сделать идеально корректно.
Олдскульные инженеры жалуются, что в современных самолётах даже нет прямой физической связи штурвалов с рулями самолёта. И если электроника отказывает, смолёт превращается в неуправляемый гроб.
В некоторых автомобилях та же фигня: руль слишком маленький, чтобы при отказе усилителя можно было управлять машиной.
Откуда берётся вера в непогрешимость ПО у ведущих инженеров - вопрос очень интересный.
Самолётная динамика на несколько порядков сложнее, там есть железо, которое надо аксиоматизировать, и ошибок в этот весь процесс можно внести уйму даже если сами инструменты идеальны, что не так, даже в случае с Coq, который тестируют интенсивнее всего.
Инженеры, в принципе, всегда учитывают, что у любой физической системы есть MTBF, ломается всё, всё нужно подстраховывать, чтобы снижать вероятность отказа.
Но в случае программных систем почему-то есть странная вера в то, что возможно сделать идеально корректно.
Олдскульные инженеры жалуются, что в современных самолётах даже нет прямой физической связи штурвалов с рулями самолёта. И если электроника отказывает, смолёт превращается в неуправляемый гроб.
В некоторых автомобилях та же фигня: руль слишком маленький, чтобы при отказе усилителя можно было управлять машиной.
Откуда берётся вера в непогрешимость ПО у ведущих инженеров - вопрос очень интересный.
Не исключено, что это не вера отдельных людей, а плохо налаженный процесс принятия решений в большой организации с размазанной ответственностью. По типу того, о чём рассказывал Фейнман про NASA, в результате расследования первой катастрофы шаттла. Низы вопили об опасностях, а принимали решения те, кто оценивал всё не так.
AZ
Не в этом дело. Вот для корректности простого градиентного спуска требуется около 100 аксиом и около 10 тысяч строк доказательств на вызывающем сомнения Lean. На Coq не известно, сколько всего потребуется.
Самолётная динамика на несколько порядков сложнее, там есть железо, которое надо аксиоматизировать, и ошибок в этот весь процесс можно внести уйму даже если сами инструменты идеальны, что не так, даже в случае с Coq, который тестируют интенсивнее всего.
Инженеры, в принципе, всегда учитывают, что у любой физической системы есть MTBF, ломается всё, всё нужно подстраховывать, чтобы снижать вероятность отказа.
Но в случае программных систем почему-то есть странная вера в то, что возможно сделать идеально корректно.
Олдскульные инженеры жалуются, что в современных самолётах даже нет прямой физической связи штурвалов с рулями самолёта. И если электроника отказывает, смолёт превращается в неуправляемый гроб.
В некоторых автомобилях та же фигня: руль слишком маленький, чтобы при отказе усилителя можно было управлять машиной.
Откуда берётся вера в непогрешимость ПО у ведущих инженеров - вопрос очень интересный.
Самолётная динамика на несколько порядков сложнее, там есть железо, которое надо аксиоматизировать, и ошибок в этот весь процесс можно внести уйму даже если сами инструменты идеальны, что не так, даже в случае с Coq, который тестируют интенсивнее всего.
Инженеры, в принципе, всегда учитывают, что у любой физической системы есть MTBF, ломается всё, всё нужно подстраховывать, чтобы снижать вероятность отказа.
Но в случае программных систем почему-то есть странная вера в то, что возможно сделать идеально корректно.
Олдскульные инженеры жалуются, что в современных самолётах даже нет прямой физической связи штурвалов с рулями самолёта. И если электроника отказывает, смолёт превращается в неуправляемый гроб.
В некоторых автомобилях та же фигня: руль слишком маленький, чтобы при отказе усилителя можно было управлять машиной.
Откуда берётся вера в непогрешимость ПО у ведущих инженеров - вопрос очень интересный.
Похоже на попытку флуд развести