Esben Skov Pedersen

Programmer, Father and Husbond

Passion for programming

In the past 10 years I've worked with business systems and distributed systems in both C# and Java, multiple scripting languages and experience with cloud computing all kinds of SQL and most recently I've grown quite fond of angularjs. I consider myself a full stack developer with a preference for backend. I've also handled devops tasks and CI setup with teamcity and deployment tasks.

I'm located in the Copenhagen area and if you need a little help with a project maybe we can work something out.

  • C#
  • Java
  • Python
  • Ruby
  • Powershell
  • azure
  • google app engine
  • angularjs
  • sql server
  • postgres sql
  • oracle
  • web api
  • mvc
  • jquery
  • .NET
  • Elastic Search
  • Domain Driven Design
  • TDD
  • Event Sourcing

I'm active on twitter.

Mostly programing related stuff.

Sometimes I answer questions

Mostly on programmers stack exchange and

Always programming related.

Unit Testing & TDD

To qoute Martin Fowler:

So there's some common elements, but there are also differences. One difference is what people consider to be a unit. Object-oriented design tends to treat a class as the unit, procedural or functional approaches might consider a single function as a unit. But really it's a situational thing - the team decides what makes sense to be a unit for the purposes of their understanding of the system and its testing. Although I start with the notion of the unit being a class, I often take a bunch of closely related classes and treat them as a single unit. Rarely I might take a subset of methods in a class as a unit. However you define it doesn't really matter.

Often I feel programmers are too hung up on treating one class as one unit. It results in more complex code because every class must be duplicated in an interface in order to be stubbed out. An often cited example is: why should the orderline class be seperated from the order class? Is there ever a situation where we want to change the orderline where we can't accept a change to the order class? In other words there is such a thing as too much abstraction.

An analogy I feel is accurate is seeing an abstraction as a seem. Say we use inversion of control and depend on an interface. This is like the seem in your jacket. The seem is required, but there is a reason out jackets doesn't have 20 seems.

There must be a balance to everything and if we fail to find this balance we end up with needlessly complicated code which is a waste of money.