История изменений

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

Так он сам и есть простая часть. Из автомата состояний крайне сложно, а иногда просто невозможно какие-то части вынуть. Там же вся суть в том, как всё соединено, а не какие части соединены.

"Как всё соединено" отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

И тесты, по-уму, писать должен не автор кода, а другой человек.

Юнит-тесты должен писать именно автор кода. Это здорово помогает структурировать код (если вместо внятной структуры - каша, то тесты писать неудобно), то есть качество кода растёт.

Кроме того, привлечение другого сотрудника автоматом влечёт затраты на оформление багов в багтрекере, затраты времени ещё и менеджера на управление багами в багтрекере (приоретизация, отслеживание, и тд), затраты на коммуникации между тестировщиком и разработчиком (и тут оказывается, что надо интровертов-аутистов увольнять нахер, и нанимать ребят с хорошими soft skills, чтобы они могли друг с другом коммуницировать). Собственно, внедрение юнит-тестирования позволяет заметно снизить возню коллектива с багами (многие баги тупо не доживают до других сотрудников).

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

Так он сам и есть простая часть. Из автомата состояний крайне сложно, а иногда просто невозможно какие-то части вынуть. Там же вся суть в том, как всё соединено, а не какие части соединены.

"Как всё соединено" отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

И тесты, по-уму, писать должен не автор кода, а другой человек.

Юнит-тесты должен писать именно автор кода. Это здорово помогает структурировать код (если вместо внятной структуры - каша, то тесты писать неудобно), то есть качество кода растёт.

Кроме того, привлечение другого сотрудника автоматом влечёт затраты на оформление багов в багтрекере, затраты времени ещё и менеджера на управление багами в багтрекере (приоретизация, отслеживание, и тд), затраты на коммуникации между тестировщиком и разработчиком (и тут оказывается, что надо интровертов-аутистов увольнять нахер, и нанимать ребят с хорошими soft skills, чтобы они могли друг с другом коммуницировать). Собственно, внедрение юнит-тестирования позволяет заметно снизить коллективную дрочку над багами (многие баги тупо не доживают до тестировщика).

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

Так он сам и есть простая часть. Из автомата состояний крайне сложно, а иногда просто невозможно какие-то части вынуть. Там же вся суть в том, как всё соединено, а не какие части соединены.

"Как всё соединено" отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

И тесты, по-уму, писать должен не автор кода, а другой человек.

Юнит-тесты должен писать именно автор кода. Это здорово помогает структурировать код (если вместо внятной структуры - каша, то тесты писать неудобно), то есть качество кода растёт.

Кроме того, привлечение другого сотрудника автоматом влечёт затраты на оформление багов в багтрекере, затраты времени ещё и менеджера на управление багами в багтрекере (приоретизация, отслеживание, и тд), затраты на коммуникации между тестировщиком и разработчиком (и тут оказывается, что надо интровертов-аутистов увольнять нахер, и нанимать ребят с хорошими софт скиллами, чтобы они могли друг с другом коммуницировать). Собственно, внедрение юнит-тестирования позволяет заметно снизить коллективную дрочку над багами (многие баги тупо не доживают до тестировщика).

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

Так он сам и есть простая часть. Из автомата состояний крайне сложно, а иногда просто невозможно какие-то части вынуть. Там же вся суть в том, как всё соединено, а не какие части соединены.

"Как всё соединено" отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

И тесты, по-уму, писать должен не автор кода, а другой человек.

Юнит-тесты должен писать именно автор кода. Это здорово помогает структурировать код (если вместо внятной структуры - каша, то тесты писать неудобно), то есть качество кода растёт.

Кроме того, привлечение другого сотрудника автоматом влечёт затраты на оформление багов в багтрекере, затраты времени ещё и менеджера на управление багами в багтрекере (приоретизация, триаж, и тд), затраты на коммуникации между тестировщиком и разработчиком (и тут оказывается, что надо интровертов-аутистов увольнять нахер, и нанимать ребят с хорошими софт скиллами, чтобы они могли друг с другом коммуницировать). Собственно, внедрение юнит-тестирования позволяет заметно снизить коллективную дрочку над багами (многие баги тупо не доживают до тестировщика).

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

Так он сам и есть простая часть. Из автомата состояний крайне сложно, а иногда просто невозможно какие-то части вынуть. Там же вся суть в том, как всё соединено, а не какие части соединены.

"Как всё соединено" отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

И тесты, по-уму, писать должен не автор кода, а другой человек.

Юнит-тесты должен писать именно автор кода. Это здорово помогает структурировать код (если вместо внятной структуры - каша, то тесты писать неудобно), то есть качество кода растёт.

Кроме того, привлечение другого сотрудника автоматом влечёт затраты на оформление багов в багтрекере, затраты времени ещё и менеджера на управление багами в багтрекере (приоретизация, триаж, и тд), затраты на коммуникации между тестировщиком и разработчиком (и тут оказывается, что надо интровертов-аутистов увольнять нахер, и нанимать ребят с хорошими софт скиллами, чтобы они могли друг с другом коммуницировать). Собственно, внедрение юнит-тестирования позволяет заметно снизить коллективную дрочку над багами (баги тупо не доживают до тестировщика).

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

Так он сам и есть простая часть. Из автомата состояний крайне сложно, а иногда просто невозможно какие-то части вынуть. Там же вся суть в том, как всё соединено, а не какие части соединены.

"Как всё соединено" отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

И тесты, по-уму, писать должен не автор кода, а другой человек.

Юнит-тесты должен писать именно автор кода. Это здорово помогает структурировать код (если вместо внятной структуры - каша, то тесты писать неудобно), то есть качество кода растёт.

Кроме того, привлечение другого сотрудника автоматов влечёт затраты на оформление багов в багтрекере, затраты времени ещё и менеджера на управление багами в багтрекере (приоретизация, триаж, и тд), затраты на коммуникации между тестировщиком и разработчиком (и тут оказывается, что надо интровертов-аутистов увольнять нахер, и нанимать ребят с хорошими софт скиллами, чтобы они могли друг с другом коммуницировать). Собственно, внедрение юнит-тестирования позволяет заметно снизить коллективную дрочку над багами (баги тупо не доживают до тестировщика).

Сложный автомат должен быть декомпозирован на простые части, каждая часть протестирована по отдельности

Так он сам и есть простая часть. Из автомата состояний крайне сложно, а иногда просто невозможно какие-то части вынуть. Там же вся суть в том, как всё соединено, а не какие части соединены.

"Как всё соединено" отлично тестируется посредством dependency injection и mock-ов. При условии, что была выполнена адекватная декомпозиция (low coupling and high cohesion).

И тесты, по-уму, писать должен не автор кода, а другой человек.

Юнит-тесты должен писать именно автор кода. Это здорово помогает структурировать код (если вместо внятной структуры - каша, то тесты писать неудобно), то есть качество кода растёт.

Кроме того, привлечение другого сотрудника автоматов влечёт затраты на оформление багов в багтрекере, затраты времени ещё и менеджера на управление багами в багтрекере (приоретизация, триаж, и тд), затраты на коммуникации между тестировщиком и разработчиком (и тут оказывается, что надо интровертов-аутистов увольнять нахер, и нанимать ребят с хорошими софт скиллами, чтобы они могли друг с другом коммуницировать). Собственно, внедрение юнит-тестирования позволяет снизить коллективную дрочку над багами, всё