Так вот это еще один показатель того, что наши законы не для честных людей, и правительству главное побольше распилить, с их капиталами им без разнице покупать с завешенной ценой или почти по себе стоимости. В любом с этих налогов только ничтожная часть идет на развитие страны(и то как на развитие, спортивные сооружения что сейчас активно строятся, не только в Сочи, в дальнейшем не принесут не какой прибыли, более того они даже не окупятся, с такой то стоимостью).
Как по мне то такие вещи не обязательно тестировать именнов в модульных тестах.
Почему бы не тестированать работу ArticlesRepository в интреграционных тестах? которые запускаются не так часто как модульные тесты?
Короче я потерял, ход ваших мыслей, в предыдущем коменте вроде как говорите про ORM, и уровень DAL, а в этом уже про бизнес логику. и про то что не стоит тестить уже написаное, тот же самый орм.
На самом деле не хочу показатся упертым ослом :), соглашусь с вашей точкой зрение, ну с одой оговоркой. Что в большенстве случаев не стоит тестировать так. Допустим тот же DataSelector, по умолчанию должен работать как нам нужно(его разработчик — по идеи написал тесты и описал как правильно работать с ним в документации). а мы не верим разработчики и пишем не нужные тесты на него, и боимся то что обыного мока будет не достаточно.
Ну так ведь это другой вид, тестирования и в юнит тестировании их не должно быть, как выше сказал унит тесты должны тестировать только одну ответсвенность, в правильном коде в котором соблюдены правила SOLID, одной ответсвенности соответсвует один класс. В итоге все другое не как не отностится к модульным тестам, в соответсвии с чем запускается намного реже.
Мне кажется или статья сама себе противоречит?
Сначало говорится, что нужно поощерять разработчика скоростью выполнения тестов, да бы он меньше курил чаще запускал эти самые тесты. А потом говорится, что мол работаем с реальной бд, с реальной сетью, etc.
Соглашусь с первой частью, что модульные тесты нужно запускать чаще. А вот все реальная работа с физическими ресурсами это уже интеграционные или приемочные тесты, которые не требуют большой частоты запусков, хотя так же важны и способсвуют быстрейшему нахождению проблем в коде.
Поработал и с тем и с другим, и могу с увереностью сказать, что у вас Синдром утенка.
Т.к. у меня совершенно противоположено представление, так как начил с .net.(могу с увереностью сказать, что и у меня тот же самый синдром).
P.S. Насчет IDE это вообще не показатель. т.к. по сравнению со всеми IDE в VS меньше всего багов.(покрайней мере раздражающих)
P.P.S. Консоль по умолчанию не закрывается в VS. Всегото нужно на другую вкладочку переключится.
Мне вот интересно на что расчитывали команды, которые делали перемещение на четвереньках или просто на коленках. Ведь строение робата как бы намекает на способ его передвижения.
А за статью спасибо большое очень интересно и душевно написано :)
Как по мне то такие вещи не обязательно тестировать именнов в модульных тестах.
Почему бы не тестированать работу ArticlesRepository в интреграционных тестах? которые запускаются не так часто как модульные тесты?
Ну так это уже совсем другая история, которая зовется «НАГРУЗОНОЕ ТЕСТИРОВАНИЕ», при которых выявляется как раз тоги, слабые места приложения.
PS. Извините не хотел не кого обидеть, не кого тролить.
Сначало говорится, что нужно поощерять разработчика скоростью выполнения тестов, да бы он меньше курил чаще запускал эти самые тесты. А потом говорится, что мол работаем с реальной бд, с реальной сетью, etc.
Соглашусь с первой частью, что модульные тесты нужно запускать чаще. А вот все реальная работа с физическими ресурсами это уже интеграционные или приемочные тесты, которые не требуют большой частоты запусков, хотя так же важны и способсвуют быстрейшему нахождению проблем в коде.
— А почему его нельзя сделать статичным он вроде потокобезопасный?
Пример с перегрузкой оператовров. Допустим сумма векрторов и тп.
Т.к. у меня совершенно противоположено представление, так как начил с .net.(могу с увереностью сказать, что и у меня тот же самый синдром).
P.S. Насчет IDE это вообще не показатель. т.к. по сравнению со всеми IDE в VS меньше всего багов.(покрайней мере раздражающих)
P.P.S. Консоль по умолчанию не закрывается в VS. Всегото нужно на другую вкладочку переключится.