ыы
или из-за кириллицы проблемы
Size: a a a
2021 February 05
АО
для xml есть миллиард готовых десериализаторов, зачем еще один формат придумывать?
АО
все же никто с этими файлами напрямую не работает
АО
их куда-то загружают и откуда-то выгружают
ыы
лапша какая-то блин
ыы
ну ладно
ыы
главное на сертификаты сдать и бухучет знать
ыы
как называется основной операционный документ
VZ
ну типа, существуют же текстовые файлы с расширениями типа cpp, cs, ts, js, c и так далее, не получилось бы сделать файл с 1с?
Для кода bsl же. xml это для форм и всего такого, весьма логично именно его использовать, Антон все верно пишет
ыы
а, ну тогда ок
АБ
нет, тесты не гарантируют и не могут гарантировать ничего. Они лишь повышают твою уверенность в чем-то
Во, нашел в закромах. Ничего нет про гарантии. Разве что про соблюдение требований
ыы
я про код
PR
Если у тебя банальный CRUD API с отчетиками, то функционал это создание вещей, чтение, отчетики и прочее
Но если тебе пришлось писать какие-то самописные решения для бд, то их же тебе тоже по-хорошему придется покрыть тестами, хотя в моем понимании это не связано с функционалом
Но если тебе пришлось писать какие-то самописные решения для бд, то их же тебе тоже по-хорошему придется покрыть тестами, хотя в моем понимании это не связано с функционалом
Есть тесты на целостность классов и типов данных - у тебя есть кастомер и у него поля имени и адреса - это стринги, ты тестишь, что ты можешь получить доступ к полям класса, если ты гетер сделал в процессе разработки приватным - получи ошибку в тесте
Есть юнит-тесты - на функциональность, условно для калькулятора - что 2+2 он выдаст 4, а не что-то другое (примитивный пример)
Есть интеграционные тесты - когда ты прогоняешь условно часть юзер-стори - добавление данных в БД, их получение, взаимодействие с другими сервисами и прочее
тесты самописок - это юнит-тесты
они гарантируют, что тот функционал, который ты прописал в тестах - они соблюдают - не более и не менее... тесты не могут гарантировать, что твой калькулятор работает ПРАВИЛЬНО и БЕЗ БАГОВ - они гарантируют лишь то, что если ты прописал в тесте ожидаемый результат 2+2 == 5 и твой калькулятор это отдаёт, то ты соответствуешь СВОИМ ожиданиям, но не ожиданиям заказчика или тестировщика... позже, если тестер прибегает с багом - ты его фиксишь и добавляешь тест на это (в идеальном мире) - и вот твои тесты расширяются - они уже ещё и под тестера/документацию/заказчика подстраиваются... и всё, не более и не менее...
Есть юнит-тесты - на функциональность, условно для калькулятора - что 2+2 он выдаст 4, а не что-то другое (примитивный пример)
Есть интеграционные тесты - когда ты прогоняешь условно часть юзер-стори - добавление данных в БД, их получение, взаимодействие с другими сервисами и прочее
тесты самописок - это юнит-тесты
они гарантируют, что тот функционал, который ты прописал в тестах - они соблюдают - не более и не менее... тесты не могут гарантировать, что твой калькулятор работает ПРАВИЛЬНО и БЕЗ БАГОВ - они гарантируют лишь то, что если ты прописал в тесте ожидаемый результат 2+2 == 5 и твой калькулятор это отдаёт, то ты соответствуешь СВОИМ ожиданиям, но не ожиданиям заказчика или тестировщика... позже, если тестер прибегает с багом - ты его фиксишь и добавляешь тест на это (в идеальном мире) - и вот твои тесты расширяются - они уже ещё и под тестера/документацию/заказчика подстраиваются... и всё, не более и не менее...
PR
именно
ыы
и еще EDT звучит как то всрато, напоминает видос где бабка пыталась зумерский сленг юзать, назвали бы Инструменты Разработки
AS
Есть тесты на целостность классов и типов данных - у тебя есть кастомер и у него поля имени и адреса - это стринги, ты тестишь, что ты можешь получить доступ к полям класса, если ты гетер сделал в процессе разработки приватным - получи ошибку в тесте
Есть юнит-тесты - на функциональность, условно для калькулятора - что 2+2 он выдаст 4, а не что-то другое (примитивный пример)
Есть интеграционные тесты - когда ты прогоняешь условно часть юзер-стори - добавление данных в БД, их получение, взаимодействие с другими сервисами и прочее
тесты самописок - это юнит-тесты
они гарантируют, что тот функционал, который ты прописал в тестах - они соблюдают - не более и не менее... тесты не могут гарантировать, что твой калькулятор работает ПРАВИЛЬНО и БЕЗ БАГОВ - они гарантируют лишь то, что если ты прописал в тесте ожидаемый результат 2+2 == 5 и твой калькулятор это отдаёт, то ты соответствуешь СВОИМ ожиданиям, но не ожиданиям заказчика или тестировщика... позже, если тестер прибегает с багом - ты его фиксишь и добавляешь тест на это (в идеальном мире) - и вот твои тесты расширяются - они уже ещё и под тестера/документацию/заказчика подстраиваются... и всё, не более и не менее...
Есть юнит-тесты - на функциональность, условно для калькулятора - что 2+2 он выдаст 4, а не что-то другое (примитивный пример)
Есть интеграционные тесты - когда ты прогоняешь условно часть юзер-стори - добавление данных в БД, их получение, взаимодействие с другими сервисами и прочее
тесты самописок - это юнит-тесты
они гарантируют, что тот функционал, который ты прописал в тестах - они соблюдают - не более и не менее... тесты не могут гарантировать, что твой калькулятор работает ПРАВИЛЬНО и БЕЗ БАГОВ - они гарантируют лишь то, что если ты прописал в тесте ожидаемый результат 2+2 == 5 и твой калькулятор это отдаёт, то ты соответствуешь СВОИМ ожиданиям, но не ожиданиям заказчика или тестировщика... позже, если тестер прибегает с багом - ты его фиксишь и добавляешь тест на это (в идеальном мире) - и вот твои тесты расширяются - они уже ещё и под тестера/документацию/заказчика подстраиваются... и всё, не более и не менее...
Изначально я говорил про "слом разрабом"
Т. е. если разраб меняет внутренности чего-то важного, то в идеале, тесты пройдутся по основным сценариям и скажут ему, что поведение изменилось. После чего разраб подумает, поведение изменилось, но это норма, или возникло нежелательное поведение
Т. е. если разраб меняет внутренности чего-то важного, то в идеале, тесты пройдутся по основным сценариям и скажут ему, что поведение изменилось. После чего разраб подумает, поведение изменилось, но это норма, или возникло нежелательное поведение
PR
а, ну да... тут уже эти триггеры на изменения зависят от грамотного проектирования тестов и обхваченных кейсов
ыы
или там Режим Разработчика
ыы
или Редактор Конфигурации
АБ
А как студия считает покрытие? Это покрытие операторов в коде?