Testing Gradle precompiled script plugins
In the previous article I discussed how to write and publish Gradle. Today, I want to show you how to write integration tests for them.

In the previous article I discussed how to write and publish Gradle. Today, I want to show you how to write integration tests for them.
Gradle has often been portrayed as an imperative build automation tool, in contrast to Maven, which is of course declarative as it relies on XML. However, Gradle has been rapidly improving and offering more and more opportunities to write build scripts more expressively and declaratively. One of such improvements are precompiled script plugins, which allow creating Gradle plugins in the same exact way as you write your project’s build script. In this article I will walk you through on how to create a precompiled script plugin and publish it on the Gradle Plugins portal. For the sake of an example I will use my gradle-kotlin-setup-plugin, which you can use as reference.
Programmers often view object-oriented and functional programming as two completely different paradigms. As a result, some developers advocate for one them, pointing out the advantages of their favorite paradigm and criticizing the “opposing” one. However, I have rarely seen anyone comparing OOP with functional programming instead of contrasting them.
Dependency injection is one of the core ideas of object-oriented programming. Being an implementation of the Tell, don’t ask principle, it lowers coupling, makes software components more independent from each other, and, as a result, increases maintainability. There two ways the dependencies can be injected: using constructors (object composition) and using dependency injection containers.
Extension method is a special language feature introduced by Kotlin, Swift and other programming languages, which allows developers to add new methods to otherwise unchangeable classes. While at first it seems like a great idea, in reality it contradicts the core OOP concepts and ideas.
Creating a motivation for developers to make unit testing part of the software development process can be challenging. Although tests can be made a requirement, without clear understanding of the practical purpose of testing, developers might write tests only to pass the code review and keep the code coverage metrics high. However, if the project manager does not force the developers to write tests, who will? I believe that it is the project itself.
DAO (Data Access Object) is an abstraction that is used for CRUD database operations. In Java, DAO is typically implemented as an interface that declares the methods through which a programmer can interact with a database table. A DTO in the form of a POJO object is used by DAO as a data container, which passes data from a programmer to the database and vice-a-versa.
After analysing the criticism about DAO, I have decided to write out my personal thoughts on this subject. In this article I will create an implementation of DAO through the perspective of SQL-speaking objects.
The well-known disadvantages of getters have already been analyzed by a number of programmers. Yegor Bugayenko has gone even further and suggested a workaround. The pattern called Printer gives indirect access to the internal parts of an object by serializing it into one of the data formats, such XML or JSON and reading it’s content using an XML or a JSON reader. As a result, as Yegor states, the object stays intact and it’s encapsulation is not violated by getters. Although this approach might seem viable at first sight, I believe that it does not solve the fundamental problem of accessor methods.