This post is a continuation of what was described in part 1.

Interested in the whole serie?
part 1
part 2
part 3
takeaways

Not A Prototype Anymore

On the second day I have started with writing tests for the things written yesterday. How come I had code but no tests? What about TDD? Well, I have explained this already, but I'm happy to repeat. I was prototyping yesterday. There was no point for writing tests for stuff that I was constantly changing, renaming, rethinking and reworking.

Today, I took a second look at all the code written previously and decided I liked what I saw. The classes which I called "prototypes" yesterday, were no longer "prototypes". They got promoted to "production code" and thus I needed to write tests for them. And so I did.

When writing tests I have discovered some misnamed methods and performed some minor changes. But all in all, the code has not changed much. It seems that I did a good job yesterday (or that I'm moving further along the same wrong path that I entered yesterday).

I have also introduced some changes to the code i.e.:

• making classes immutable,
• introducing factories

Improving the E2E Test

At some point I realized that I have gone too far with my unit tests, and that I started to add some new functionality (for stuff that wasn't important) so I quit, and went back to my end-to-end test.

My E2E test... Eh, I tell you it was ugly. It wasn't even 100% automated, because I haven't written real assertions. The test was merely printing out some data so I could figure out whether the result was fine. This was good for the beginning but not anymore! Another issue was a nasty Thread.sleep lurking in the depths of the test code. Yuck!

I got rid of the Thread.sleep with Awaitility (I have to admit it got even nicer when using lambdas!). But there was more to it. I had to make it possible to configure the application, so I could run some background scheduled tasks much more frequently when running my application for the purpose of end-to-end tests.

I have also worked to make this test stronger and more readable. I factored out a method for sending events, and even wrote a custom assertion (but later replaced it with .extracting("some property") provided by AssertJ).

Fake Gotcha!

I set a trap and fell into it myself. :) Basically, I got so used to the fact that my end-to-end tests rely on some database, that I forgot that I have no database implemented yet, but only in-memory fakes. The result was, that when in reality everything worked fine, my test failed repeatedly. Why? Because the verification part relied on the different instance of the fake service than the production code. I solved this using the static keyword. Good enough for now.

When You Are Stuck...

...and you know what helped me when I was struggling with the issue described above? I took a break, had a dinner and then when I was coming back... voila! It just happened, I got the solution I was looking for.

Another time I couldn't figure out why Spring is not wiring some of my beans. I opened my mouth to talk to one of my colleagues, and opened a class to show him... and then I saw it! It was obvious why the stuff wasn't working as expected.

Moving Stuff Around

I thought yesterday that everything has found its place, but I was wrong. Today I have discovered some classes which begged me to move them to where they belong.

Slower Then Expected

I admit I move slower than expected. I hope this no-rush approach will make the code better. Time will tell.

Extreme BDD

As you have probably already realized, I'm following the path of BLOG Driven Development technique. What it means, is that before I write a single line of code, I first ponder about how I'm gonna describe it on my blog. Pretty sick, isn't it? ;)

(picture from paperblog.com)