Kastor Driver

From recent times I started to planning my goals for next half of the year. It also applies to books which I have to read. One more half of the year passed, so it's time to sum up.

Usually our programs depends on third party services. That create some inconveniences for testing, but if we write our unit tests correctly it is not a problem to mock part of code that interacts with third party service. But, what about UI tests? What should we do if we have to test program behaviour that appear only after specific response from third party service?

Last time we discussed significance of unit tests. They must be clean, fast and also comprehensive. First two points developer can control manually. But what about the last? Value of tests is directly proportional to the code coverage. Of course the level of code coverage is not a main purpose, but it is a good sign of their usefulness. How can we control and maintain this rate on sufficient level? Cobertura maven plugin will help us.

Everyone who cares about quality of his code must write tests. Would be better to write tests before code (I mean TDD), but presence at least some kind of tests are already well. Tests are the best way to prove that your code works as well as you expect. Also your tests are the best documentation not only how to use your code, but also how you understand a task.

Продолжаем наш батл между Java 8 и бандой четырех. Сегодня под колеса новых возможностей православной Java попал паттерн “Стратегия”. Но не будем спешить и для начала вспомним о чем вообще данный шаблон проектирования. Стратегия - поведенческий паттерн, задачей которого является определение и инкапсуляция группы алгоритмов, а также обеспечение их взаимозаменяемости. Это позволяет нам менять реализацию поведения на лету. Освежим в нашей памяти UML-диаграмму данного шаблона.

До недавнего времени я считал паттерны проектирования некими незыблемыми постулатами, которые нужно знать на память как и таблицу ASCII (шутка). Но о чем я не подозревал, так это о том, что некоторые паттерны были рождены только потому, что на тот момент некий язык программирования просто не имел необходимого функционала для решения определенной задачи. И, как оказалось, с развитием языков программирования зарекомендовавшие себя подходы к решению стандартных задач могут претерпевать некие изменения или же вообще становиться антипаттернами. Возможно название заметки чересчур воинственное, т. к. в некоторых случаях новые возможности Java 8 не столько противопоставляются шаблонам проектирования, сколько совершенствуют их. Давай посмотрим с точки зрения Java 8 на шаблоны проектирования, некогда описанные бандой четырех. Погнали!