Screenshot

I often face lagacy code which has a lack of tests and is not designed to be tastable.

A typical problem are static methods used by components you want to test but cannot be mocked (except using tools like PowerMock which for me acts more like an air freshener for code smells). To start writing unit tests, it is helpful to refactor the static helper to become an injected dependency.

First step is to introduce a static singleton instance to be able to make methods non static later:

class MyHelper { static boolean isWhatever(MyType param) {…} }

Second we copy all public methods and replace the old static ones by using the singleton instance:

class MyHelper { static final MyHelper INSTANCE = new MyHelper(); static boolean isWhatever(MyType param) { return INSTANCE.isWhatever(param); } boolean isWhatever(MyType param) {…} }

Third step is to inline all invocations of the static method usage:

class MyHelper { @Deprecated static final MyHelper INSTANCE = new MyHelper(); boolean isWhatever(MyType param) {…} }

Last step is to make the singleton an injectable bean. With Spring framework this can look like the following:

@Component class MyHelper implements FactoryBean<MyHelper> { @Deprecated static final MyHelper INSTANCE = new MyHelper(); boolean isWhatever(MyType param) {…} MyHelper getObject() { return INSTANCE; } CLass<MyHelper> getObjectType() { return MyHelper.class; } boolean isSingleton() { return true; } }

Now you can start to replace usages of INSTANCE by injection. This can be done step by step. You may have to live with this state for a while.

At the end the factory bean implementation and the static singleton field can be removed.

@Component class MyHelper { boolean isWhatever(MyType param) {…} }

Now we reached more or less the original amount of code. Was it worth to do so?

When looking at Java libraries (especially internal ones) with support for Spring framework I often find classes annotated with @Component or @Configuration to manage components by classpath scanning. Unless you use conditional ones like supported by Spring Boot this creates hard runtime dependencies difficult to set up for production and especially for tests.

The only way "traditional" way to enable different configurations is to use multiple profiles but for this verybody has to use the same profle names (even this got better by the option to use negated profiles). Nevertheless this often ends up in huge contexts also in tests triggered by transitive bean dependencies as internal libraries often share toplevel packages and some developers tend to by lazy by simple using a component scan on the toplevel package of the company.

To avoid this and create small contexts without conflicts for fast test setups, component scan should not be used at all. As even Spring Boot includes automatic scans this implies to ban the usage of annotations like @Component and @Configuration. But it would be hard to setup each configuration for all used libraries by hand for all tests and production. From my experience it is a good approach to start with some configuration classes named by purpose offering a bunch of beans by @Bean annotated methods. For the real configuration of the context use @Import introduced with Spring 3 on the not annotated configurations or leave them out when you simply want to mock out some dependencies.

public class PartialConfig { @Bean @Autowired Whatever whatever(WhateverDependsOn dependency) { return new TheDefaultWhatever(dependency); } @Bean WhateverDependsOn somethingStrange() { ... } } @Configuration @Import({PartialConfig.class, ...}) public ProductionConfiguration { ... }

As a test may not like to depend on some strange beans, he could simply do so:

@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = TestConfig.class) public class MySpringIntegrationTest { @Autowired Whatever whatever; @Test public void testWhatever() { ... } public static class TestConfig { @Bean Whatever whatever() { return Mockito.mock(Whatever.class); } ... } }

I had an old OpenSource software project which I wanted to rewrite for training purposes. As the project was years old I decided to rebuild it from scratch and also choose "state of the art" hosting.

Even if the project was versioned using subversion in formaer times, nowadays you would use git as a more powerful but widely used VCS. So to settle on GitHub was a typical choice. And also using a modern branchng model in a minimal way was not a hard one (develop for unreleased, master for last release).

So I created a repository on GitHub including some documentation and license. As the project was a Java library, I had to use a build tool. Gradle is the best compromize here, imho. It combines conventions over configuration with support for easy customizations if needed.

Ok so far, now doing the real work. Implemented the functionality, setting the version, creating artifacts like JAR, sources and documentation - done. Next? To make the library public.

The typical ecosystem uses dependency management fetching everything needed from a repository as maven introduced it. But publishing to Maven Central is not as easy as retrieving from it, especially if you do not even use maven. Looking around for a more flexible solution I found jCenter beeing part of Bintray. For OSS using Bintray is free and includes the option to sync with jCenter which is a widely supported repository. So signing up, creating a package and publishing to Bintray was easy with gradle. And applying a sync to jCenter took just a day for the first release, further version are synced automatically.

Ok, but what about quality assurance? Of course I created automatic unit and integration tests and I normally run them before check in. But anyway, maybe I forget about it… And what about contributors? I want continious integration. A really easy setup using GitHub integration is offered by Travis CI. It has automatic build tool detection, configurable builds, notifications and is also free for OSS. Next signup (just a click with GitHub sign on) and an easy two line YAML config later, I have a running CI environment.

When writing a web frontend with JavaScript like AngularJS and a Java backend with a REST API but also delivering the JS client including some complex data to initilize in HTML, you may encounter some strange problems with encoding and escaping.

Each of the techniques involved has a different set of characters which are "safe" and other which need to be escaped or encoded for another technique (incomplete):

JavaScript: single ticks, brackets

HTML: quotes, angle brackets

URL: slashes, equal signs, ampersands, hashes

The idea is to pass complex data as Base64 encoded Zip file containing JSON. This can be created by the backend, passed as an Angular data Attribute and decoded by a REST call later. So only the backend needs to know how to encode and decode the data.

But therefore it would be helpful to have a Base64 variant without the need to escape or encode anything. RFC 3548 includes a "URL and Filename safe" Base 64 Alphabet which is nearly what you need, just the padding is still an equal sign. By replacing this with a dot you get a Base64 variant which is safe without any escaping for all techniques! Lets call it Safe64.

BTW: Jackson2 has a Base64Variant wich supports this perfectly:

In a project I work I sometimes find crude code as many other people do. For me, a unit test is also a living documentation of the behaviour of the code.

Here are some of my "higlights" of code written by an international well known contractor. Please do not blame the employees, as I am sure the problem is also about management, goals and priorities.

Ignore failures

To write a test is sometimes hard work so I really don't understand why to make it completly useless with the following code fragment:

@Test public void testWhatever() { try { … } catch (final Exception exception) { Assert.assertTrue(true); } }

But findbugs is happy with this as the catch block is not empty. And of course, the test will never fail! And it creates a good coverage! Perfect!

Most of the other tests contain a assertNotNull() as the best case. But I think the goal was just "write tests that pass and have a high coverage".

Cluttered Code

I have no idea why, but I also found javadoc and trace logs in unit tests:

/** * Test something. * * @throws IOException Signals that an I/O exception has occurred. */ @Test public void testSomething() throws IOException { if (LOGGER.isDebugEnabled()) { LOGGER.debug("Inside MyTest->testSomething()"); } … if (LOGGER.isDebugEnabled()) { LOGGER.debug("Exiting MyTest->testSomething()"); } }

The build tools I use create test reports and I like test method names describing the tested behaviour so I don't need additional documentation.

Mock as mock can

When creating unit tests it is essential to mock dependencies so you can control them and be sure any error is not elsewhere. But you can also do too much:

public class MyHelperUnitTest { @Mock private UnitsInDTO unitsInDTO; @Mock private List<unitsindto> unitsInDTOList; @Mock private LocationModel locationModel; // 21 more mock declarations … @Before public void setUp() { Iterator<unitsindto> unitsInDTOIterator = Mockito.mock(Iterator.class); Mockito.when(unitsInDTOList.iterator()).thenReturn(unitsInDTOIterator); Mockito.when(unitsInDTOIterator.hasNext()).thenReturn(true).thenReturn(false); Mockito.when(unitsInDTOIterator.next()).thenReturn(unitsInDTO); // 70 more lines of behaviour definition …

I like Mockito very much but mocking a list of DTOs, sorry, this is not clean code! It is good if you know how to use a mocking framework, but it is even better if you also know when.

Conclusion

Gradle is a very cool build system I like very much. But versioning and artifact upload is not very convenience. How to handle versions, repositories and branches in a quite simple way?

Branching

When using gitflow there is a simple rule: develop and future branches create snapshots, master creates releases.

ext { branch = getBranch() buildType = getBuildType(branch) }

But how to get the branch and build type? That is simple in groovy:

def getBranch() { return "git rev-parse --abbrev-ref HEAD".execute().text.trim() } def getBuildType(branch) { switch (branch) { case ~/^(master|version.*)/: return 'RELEASE' default: return 'SNAPSHOT' } }

Versioning

Following semantic versioning I created the following entries in gradle.properties:

majorVersion=1 minorVersion=0 patchVersion=0

The build.gradle defines the full version (outside of ext):

version = "${majorVersion}.${minorVersion}.${patchVersion}.${buildType}"

The tricky part is: when to change the version on which branch? Using release branches, this would be a good choice as any change will also be merged to master and develop, but: the snapshots will have the wrong version! So you will have to change the version on develop after a release (or its branch) has been taken. When changing the patch version on a hotfix branch, do not merge that change of gradle.properties back to develop!

Publishing

The rest is using the maven-publish plugin. Now it is easy to upload artifacts to a binary repository like artifactory:

apply plugin: 'maven-publish'

Typically repositories have different parts for snapshots and releases. This can be determined automatically depending on the branch in build.gradle:

ext { repo = "${buildType}" == 'SNAPSHOT' ? 'libs-snapshot-local' : 'libs-release-local' } publishing { publications { mavenJava(MavenPublication) { artifactId "${archivesBaseName}" from components.java artifact sourcesJar artifact javadocJar } } repositories { maven { credentials { username "${artifactoryUser}" password "${artifactoryPassword}" } url "${artifactoryUrl}/${repo}" } } } publish.dependsOn build

You only need some more entries in gradle.properties:

artifactoryUrl=http://server:8081/artifactory artifactoryUser=deployer artifactoryPassword=

You should define the password with an option when calling the script which is now also easy to use from local and CI servers:

gradle clean publish -PartifactoryPassword=xyz

Continious builds for master and develop can always publish with this aproch.