Mark van Venrooij

Mark van Venrooij's blog

Tag: TDD (page 1 of 3)

Learning domain-driven design

On my new job the department is applying Domain-Driven Design. I did read Domain-Driven Design – Tackling Complexity in the Heart of Software by Eric Evans a couple of years back. However as I never used it I need to learn how to apply it. So in order to really learn DDD I started to reread Eric Evans’ book and plan on reading Implementing Domain-Driven Design by Vaughn Vernon. As theory and practice are only equal in theory, I want to apply DDD to my favorite pet project. To recap an earlier blog post, many years ago I started categorizing all my financial transactions. At first I used to build a tool myself to give me insight in my spendings, later I bought something to do this for me. However this is now the domain I know pretty well and use to learn new things.

Current progress

Currently I read till chapter 5 of Eric Evans’ book. The key things I learned in the first chapters:

  • Make domain concepts explicit by capturing the knowledge in the design
  • Define a ubiquitous language using domain terms
  • The feedback loop from coding back to the design is often missing
  • The domain must be isolated from the user interface, db glue and other supporting code in order to achieve separation of concerns
  • The smart UI cannot be combined with DDD

Moving forward

My plan is to finish reading both books before the end of the year. (I hope I can find the time, given that I have a young daugther.) In the same time I plan to work on my pet project. As I learned long ago a good way to learn things is to teach others. So I want to share my progress in implementing DDD on my pet project through this blog. So the coming weeks expect some new blog posts on this topic. Basically me struggling to apply the DDD concepts.

Adjust design to get green bar

pragmatic programmer

pragmatic programmer

A while ago I read the pragmatic programmer. In the book are many tips listed. In the back of the book there is an tear-out card with all the tips collected. As I’m working on different locations all the time I rarely look at the card. The tips however seem very useful to me. Therefore I created a small Google App engine application that sends me a random tip every day. TDD-ing my way through the requirements I now get a tip every day. During the development I ran into one little problem with stubbing my randomizer method.

For the unit-tests testing sending the mail I needed to stub the random result to give a certain result. So I could check that the rest was working. For mocking & stubbing I use Mockito. The normal way you stub a method in a class is to create a mock version of the class and use the when-then pattern as documented over here. The problem I had was however that the method getting the random result was part of the class under test. This resulted in the test failing because sending the mail was never being executed as it was a Mock. Please see the code below:

And the test looked like this:

Please note that I use TestNG as testing framework. In TestNG the expected and actual result are reversed if you compare it to JUnit.

So all my tests where failing. In order to get a green bar again I need to adjust my code to be able to test it. After a lot of thought I created an extra class that contains only the randomizer method to pass it into the repository as a dependency.

And the test now looks like this:

Of course you can argue that getting a random number is not the responsibility of the Repository and that therefore the new design is better. But in the old situation the random number was coming from the Java API. Therefore it was not a responsibility of the Repository either. I’m happy to have a green bar now, but I don’t like changing the code just for the tests to be passing. Please let me know your thoughts in the comments or via Twitter.

Review: The clean coder

Cover of the clean coder

The clean coder

Last week I finished reading The clean coder written by @unclebobmartin. The book’s subtitle: “A Code of Conduct for Professional Programmers”, summarizes the book quite good.

Throughout the book @unclebobmartin tells about his own experiences during his career. Also he illustrates the points he wants to make with excellent example discussions between (project) managers and developers. These example stories are quite entertaining and make the book easy to read.

The first few chapters discuss how a professional developer behaves as a person. It’s all about managing expectations & making sure that you’re in the right state to do your job. After that some practices that improve the quality of your work are introduced. Examples practices are TDD, testing in general and estimation. The last chapters discuss how to behave in a team. A embarrassing paragraph in these chapters is called “Degrees of failure”. In that part @unclebobmartin basically explains how the education system fails to educate software developers.

It’s a nice book to read and has nice suggestions how software developers can improve their work and become craftsmen. However many of these tips are not new to me. They can be found in the enormous blob of blogs about agile / lean / etc. development. Only the estimation chapter gave me some real new information. Because the book is written in @unclebobmartin’s distinctive style I still recommend the book. The pragmatic programmer is a different league though.

Working with ATG

ATG by delete08, on Flickr

ATG by delete08, on Flickr

Now I’m working with ATG for a couple of months I want to share my thoughts on the platform so far. Let me first introduce ATG. ATG is an ecommerce platform. It promises to deliver out of the box functionality to create complex ecommerce websites. That’s all I want to say regarding the bullshit bingo. Today I’ll discus ATG as seen by a developer. There are many other perspectives to see if the software suits your needs.

In April this year I attended an ATG course containing three modules: “Foundations of ATG”, “Extending the ATG platform” and “ATG Personalization and scenario development”. As you can guess these are modules targeting a developer. There are lots of other courses for business users etc. Just as a reminder before working on ATG I used to be working on all kinds of JEE applications. Furthermore I developed some (test) projects in Ruby (on Rails) and used Google app engine to see the advantages of a cloud platform.

At first it was a shock to work with JSP files again. I was used to JSF / ZK and other component based GUI toolkits. JSP files seemed so old to me on certain moments. As a fact the whole platform feels a little bit out-dated. As an object-relational-mapper ATG basically uses a special kind of HashMap to represent the entities. If you are used to Hibernate/JPA or active record like technologies accessing entities properties with Strings feels not ideal. Maybe I just need to get used to it. The repositories are mapped to the actual database through XML.

ATG uses property files for dependency injection. Unlike Spring these are not in a XML format but just key-value pairs. This makes the property files much more compact. One disadvantage is that (just like Spring/hibernate etc.) it can result in a config hell. I’m not sure anymore if configuration over code is a good mantra. But I’ll save that discussion for my review of the pragprog book.

ATG uses Servlet beans (a.k.a. droplets) to couple the JSP files to the other Java Components. Servlet beans normal servlets but there is an ATG tag handler that lets you access them directly in your JSP.

Let me give an example of using a servlet bean:

A java class handling this droplet extends some base class containing a service method and may look like:

Furthermore we need a config file (named to map the servlet bean to a class. This config file is also used for dependency injection (someComponent).

ATG provides several out of the box servlet beans and components for commonly used operations.  For most (java) web developers this pattern is pretty familiar. One possible problem of these droplets is that some people may link up many of them. This results in pretty long JSP files with a lot of logic contained in them. But as Uncle Ben told us:

With great power comes great responsibility

So how do I feel about ATG? It is just another java development platform. It has its quirks and feels outdated sometimes, but any platform has its issues. ATG is just an implementation of ideas also used in JEE.

– Default functionality available

– Tends to lead to lots of logic in JSP files.
– Repositories are Hashmaps

Vergelijking tussen Intellij Idea en Eclipse

Idea by Judy **, on Flickr

Idea by Judy **, on Flickr

Nu ik een tijdje gebruik maak van Intellij Idea wil ik een korte vergelijking maken tussen Intellij Idea en Eclipse. Om preciezer te zijn een vergelijking om te werken aan een Google App Engine project. Volgens de website is (de betaalde ultimate edition van) Intellij Idea geschikt om Google App Engine (GAE) projecten mee te ontwikkelen.

Waar in Eclipse alleen het toevoegen van een plugin voldoende is om te starten met een GAE project kost het in Idea meer tijd om je omgeving werkend te krijgen. Enkele voorbeelden:

  • Apart downloaden van GAE is noodzakelijk
  • Zelf de project settings aanpassen zodat de shared libs beschikbaar zijn tijdens het compileren
  • In de project settings het web artefact aanmaken

Met de Eclipse plugin ben je dus sneller onderweg.

Voordelen van Intellij Idea zitten wat mij betreft in de betere support voor java code in het algemeen. Onder andere:

  • Als je unittests zijn ingedeeld in groepen is het mogelijk om alleen 1 test groep (alt-shift-f10) te runnen. In Eclipse is hetzelfde mogelijk maar daar heb je je muis voor nodig.
  • In Intellij Idea wordt bij het kopiëren/plakken van een string die json bevat in een java class automatisch geescaped! Klein voordeel maar het maakt je leven weer makkelijker waardoor je je kunt focussen op de echte problemen
  • Eenduidige short-cuts voor refactoring

Ik vergeet vast nog heel veel dingen die Intellij idea geweldig maken. Noem jouw voordelen en nadelen in de comments.

Older posts

© 2018 Mark van Venrooij

Theme by Anders NorenUp ↑