At the red-green-refactor carousel – implementing conversion unit Skip to content →

At the red-green-refactor carousel – implementing conversion unit

After having gestures handled and stored, we are ready to create simple logic for the Conversion Unit. In the following post, I’m going to describe created architecture. All of the code was written with TDD, because one of my goals for “Get noticed 2017” competition is to become more fluent in using TDD as a daily basis. Up till now, it’s going well.

The short introduction for those who are not familiar with TDD. Test Driven Development is a technique where, at the beginning, you write a test that does not compile (red part). When it is ready, then you start to write the code until it passes (green part) written test. At the end of an iteration you should look through the code and do refactoring if needed (refactor part). Good practices show that tests should be as simple as possible. In the ideal world, when a class is completed, then tests cover 100% of its lines.

I would like to remind you that all of the sources are available in my Github repository. Moreover, in the README file, you can find short project description with its main assumptions.

Architecture description

Let’s start with the code. The class, which as an argument takes Password and as a result returns its String representation, is PasswordConversionService.

Everything we should do before converting passwords is to register appropriate converters.

I’ve prepared only two converters so far. One for gesture elements and one for character elements. CharacterElementConverter is not interesting because there is no sophisticated logic:

GestureElementConverter is a little bit more complicated. As I mentioned in the previous post, we can choose a lot of different strategies for gesture recognition e.g. function interpolation, artificial intelligence. Basing on this assumption, I created IConversionStrategy interface which should be implemented whenever a user needs to change system behavior. I prepared only one version of a strategy which is called LinearConversionStrategy. It treats gesture as a line and counts its angle of inclination.

When the angle of inclination value is prepared, then IDirectionResolver implementation takes it and makes a decision about line direction (vertical, horizontal, diagonal left/right). Having direction, conversion strategy has enough data to prepare final result – Shape object ( Line is a subtype of Shape).

Shape classes should override toString method which is used to convert Shape object into its textual representation. In a case of Line class, toString returns concatenated class name and direction.

At the end of the flow, PasswordConversionService uses values returned by converters to build final result.

Unit and mutation tests, coverage

For coverage gathering purposes I used PIT tool. The screen below shows a dash of statistics:

As you can see, some improvements are required. I hope to make them in the near future.

I decided to write conversion logic without using Spring framework. This approach convinces that there are no framework-related methods or classes. In the next stage, I’ll integrate conversion logic with Spring.

For end-to-end tests, I created simple test class called AksesiIntegrationTests where no mocks are used. In the setup method, the PassowrdConversionService is configured. Each of tests checks different elements combination. It is also the best class to follow if you don’t understand how exactly Aksesi Proxy will be working.

TODO

Proposed implementation is far from the perfection. There are many known bugs or poor solutions. First of all, the method PasswordConversionService.removeAllConverters() should be implemented in a better way. I’m still looking for a safer solution.

Another issue is connected with the PasswordConversionService.process(Password) method. What should we do if converter for given type is not registered? Skip this element? Generate default string? It needs consideration.

Furthermore, there are also places where refactoring is required. Class LineDirectionResolver does not look in a way that makes me feel satisfied.

 

In this post, I described naive Conversion Unit implementation. This solution allows us to build an application which will provide basic functionality for Aksesi Proxy assumptions. In the Monday’s post, I’m going to write a few words about the security of this idea.

I would like to remind you that all of the sources are available in my Github repository.

Have a nice day 🙂