Дочитать книгу Test-driven Java development
Есть такая шикарная книга по TDD
Читаю в оригинале, и часто бывает очень лень. Этой целью хочу добить эту книжку. И да, для лучшего понимания писать после прочтения Summary писать короткий отзыв по главе - чтобы что-то оставалось в головушке.
Критерій завершення
книга прочитана
Особисті ресурси
время
Екологічність мети
хорошее понимание методологии TDD
-
Глава 6
6: Mocking – Removing External Dependencies
- Mocking
- Mockito
- The Tic-Tac-Toe v2 requirements
- Developing Tic-Tac-Toe v2
- Integration tests
- Summary
-
Глава 7
7: BDD – Working Together with the Whole Team
- Different specifications
- Behavior-driven development
- The Books Store BDD story
- JBehave
- Summary
-
Глава 8
8: Refactoring Legacy Code – Making it Young Again
- Legacy code
- The Kata exercise
- Summary
-
Глава 9
9: Feature Toggles – Deploying Partially Done Features to Production
- Continuous Integration, Delivery, and Deployment
- Feature Toggles
- A Feature Toggle example
- Summary
-
Глава 10
10: Putting It All Together
- TDD in a nutshell
- Best practices
- This is just the beginning
- This does not have to be the end
Висновок
So, let's sum up all the things here.
TDD approach based on red-green-refactor pillar. From fail to success till perfection. One of the forms of TDD is BDD, what stands for Behavior Driven Development. Unlike TDD, BDD is written by any member of a team and then implemented in code.
Best practices
- Write tests before implementation
- Only write new code the the test is failing
- Rerun all tests every time the implementation code changes
- All tests should pass before a new test is written
- Refactor only after all tests are passing
- Write simplest code to pass the test
- Write assertions first, act later
- Minimize assertions in each test
- Do not introduce dependencies between tests
- Tests should run fast
- Use test doubles (mocks, spies)
- Use set-up and tear-down methods
- Don't use base classes in test
Tools
Code coverage: JaCoCo, Clover, Cobertura
Continuous integration: Jenkins, Hudson, Travis, Bamboo
BDD: JBehave, Cucumber
Щоденник мети
The 9th chapter has been finished. When you use continuous integration/delivery/deployment it's stated that every your commit that passes all the test during the build might be delivered right to customer. But in some cases this decision should be made by a PM or someone else, not by machine or a process. Also there's an issue that can be caused by a fact that feature is done partially, and even it passes all the tests, the functionality could not yet be ready. For solving this two issues there's an approach calling Feature Toggles. You have some settings file with the list of your features. And your services always check this file whether a feature is enabled or not. For more convenient code there're some libraries for solving this issue:
And the rest of the chapter was about example of using these libs. Quite simple.
Have finished the 8th chapter. About legacy code and refactoring of it.
"Legacy code" means code without tests - by Michael Feathers. Other ways to recognize legacy code:
- a patch on top of a patch, like living Frankenstein;
- known bugs;
- changes are expensive;
- fragile;
- difficult to understand;
- old, outdated, static or non-existend documentation;
- shotgun surgery;
- broken windows.
While non-legacy application is:
- easy to change;
- generalizable, configurable and expansible;
- easy to deploy;
- rubust;
- no known defects or limitations;
- easy to teach to others/to learn from others;
- extensive suite of tests;
- self-validating;
- able to use keyhole surgery.
There was an example with lack of dependency injecton. So it should be changed to DI mechanism and tested.
- The legacy code change algorithm:
- identify change points;
- find test points;
- break dependencies;
- write tests;
- make changes and refactor.
Mentioned techniques and tools: DbUnit, RestAssured - library to test REST and JSON, http://xunitpatterns.com
Well, I've finished the 7th chapter. It was about BDD approach.
BDD states for Behaviour-Driven-Development. It similar to TDD and has in common that you should write tests first. But there are some differences:
- BDD tests works much longer than TDD (unit-tests);
- BDD tests are used for acceptance, they don't dive into implementaion details;
- BDD test are readable by anyone of project team, not only developer like in TDD.
Frameworks & tools:
- JBehave (BDD framework)
- Cucumber (BDD framework)
- Selenium, Selenide for UI tests
- PhantomJS - headless browser for UI tests (COOL!)
In BDD you write scenario - plain text about some specification, readable by any of project team, not only developers. It uses given-when-then notation. This scenario is mapped on a parsing and implementaion class, where scenario phrases mapped (via regexp) on your methods (via annotations).
More info:
Поскольку книга на английском, решил, в целях сочетания полезного с полезным, публиковать отчеты о главах тоже на английском. Итак, 6 глава прочитана.
Well, the 6th chapter has been read. In this chapter was introduced mocking technique. Mocking - means when you isolate and substitute your dependencies with dummy, or `mock` objects. There used Mockito - one of the most popular mocking framework.
Main use case looks like this:
List list = mock(List.class);
doReturn(10).when(list).size();
There are 2 kinds of mock objects: mock and spy. Mock is a real dummy objects that doesn't anything unless we specify otherwise. Spy uses a real object and invokes real methods unless we specify otherwise.
Mocking is used in TDD approach in order to:
- increase speed of your unit-tests.
- uncouple your dependencies from your testing module.
