Я уже НЕ РАЗ давал ссылку на вот эту статью - http://blog.lowendahl.net/ndc2010/ndc2010-michael-feathers-the-deep-synergy-between-good-design-and-testability/
Но она - ТОГО СТОИТ.
Теперь "украду оттуда" САМУЮ ГЛАВНУЮ МЫСЛЬ.
А она заключается вот в этой таблице:
Перевести эту таблицу на русский для интересующихся? Или сами справитесь? Или может быть "свои комментарии" к ней написать?
Но она - ТОГО СТОИТ.
Теперь "украду оттуда" САМУЮ ГЛАВНУЮ МЫСЛЬ.
А она заключается вот в этой таблице:
Catalogue of testing pains and relation to code smells
State hidden within a method – you find yourself wishing you could access local Variables in a test. | Methods are typically to long and are violating Single Responsibility Principle. |
Difficult Setup – Instantiating a class involves instantiating 12 others. | This pain says something about the design, it means that the class isn’t factored into smaller pieces. Problem: To Much coupling. |
Incomplete shutdown – pieces of your code lose resources and you never realize it until you test. | Classes don’t take care of themselves, poor encapsulation. |
State-leaks across tests – The state of one test affects another. | Smells of improper use of sIngletons or other forms ofglobal mutable state. |
Framework Frustration – Testing in the presence of a framework is hard | Insufficient Domain separation. Lacking good separation of concerns. |
Difficult mocking – You find yourself writing mocks for objects returned by other objects | Law of Demeter Violations |
Difficult mocking 2 – hard to mock particular classes | Insufficient abstraction and / or dependency inversion violation. |
Hidden effects – you can’t test a class because you have no acess to the ultimate effect ot its execution | Insufficient separation of concerns and encapsulation violation |
Hidden inputs – There is no way to instrument the setup conditions for a test through the API | Over encapsulation, insufficient separation of concerns |
Unwieldy parameter lists – it’s too much work to call a method or instantiate a class | To many responsibilities in a class or a method. SRP violation |
Insufficient access – you find yourself wishing you could test a private method. | To many responsibilities in a class. SRP violation |
Test Trash – many unit tests change whenever you change your code. | Open/Closed violations |
>> Или может быть "свои комментарии" к ней написать?
ОтветитьУдалитьОдна строка таблицы - один поясняющий пост :) Микро, но с пояснениями. Можно с кодом :)
Ок. Напишу. Но не сразу.
УдалитьТем более, что сегодня на работе провёл 11-ть часов. Ну просто время за давно уже актуальным рефакторингом пролетело незаметно. Так что сейчас - не до вдумчивых комметариев и постов.
Удалить