Показать сообщение отдельно
Старый 14.03.2017, 23:16   #48  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
кроме того, что это фишка аксапты, если я правильно понимаю.
Дефолтные параметры ? Да они даже в C# есть

PHP код:
public void ExampleMethod(int requiredstring optionalstr "default string",
            
int optionalint 10
Цитата:
А вот тут похоже и есть корень.
В аксапте чаще наоборот. И об этом писал fed выше.

Мой код использует что-то из стандартного функционала аксапты.
как правило, я не до конца понимаю как работает стандарт на всех граничных значениях.
как правило, я не понимаю нафига сделано именно так.
Нет, мне кажется мы по разному понимаем unit тестирование. И мне кажется что мое понимание ближе к "каноническому"

Тест который тестирует твой код, и тест который тестирует стандартный функционал, который использует твой код - это разные тесты.

В тесте, который тестирует твой код - не надо проверять стандартный функционал. Может быть его вообще лучше замокать. Для проверки стандартного функционала будут свои unit тесты.

Каждый unit тест не проверяет весь мир вокруг. Он проверяет изолированный кусочек кода.

Код настолько легко будет тестировать с помощью unit-тестирования, насколько легко из него можно будет вычленять вот эти независимые кусочки. Код, который ты привел, с точки зрения тестирования - жесть. Его невозможно рассматривать независимо от всего мира вокруг. Он работает напрямую с таблицами БД, он обращается к статическим методам других таблиц. В него встроена (а не передается снаружи) обвязка для кеширования уже посчитанных значений. Это означает, что я не могу передать для нее mock. А надо. Так как это кеширование должно проверяться отдельно от этого метода, в отдельном unit тесте. А здесь я хочу тестировать логику метода.

У кода есть разные характиристики. Например, его производительность (насколько быстро он работает), читаемость (насколько легко читать код), поддерживаемость (насолько легко добавлять в код новые возможности). А еще есть такая характеристика, как тестируемость. Насколько легко код тестировать. Как и во всех остальных случаях, тестируемость кода не возникает сама по себе. Для этого надо прилагать дополнительные усилия. Иногда тестируемость может вхождить в конфликт с другими требованиями к коду. Например, с производительностью или даже читаемостью.

Очевидно, что у разработчиков Ax тестируемость кода не была приоритетом номер один.Скорее всего вообще, она не была в приоритетах. Я не говорю, что это плохо для продукта в общем. Наверное, расставив приоритеты таким образом они что-то и выиграли. Но, на мой взгляд, этот выбор привел к тому, что Ax и unit тестирование не рассматривают вместе.

Последний раз редактировалось Андре; 14.03.2017 в 23:35.