markhneedham/blog huggingface dataset:
TDD: Testing sub classes
Date: 2009-09-13 22:21:22

We ran into another interesting testing dilemma while http://www.markhneedham.com/blog/2009/09/13/coding-an-abstract-classasp-net-mvc-dilemma/[refactoring the view model code which I described in an earlier post to the point where we have an abstract class and three sub classes] which means that we now have 3 classes which did the same thing 80% of the time.

As http://www.markhneedham.com/blog/2009/09/02/coding-reduce-fields-delay-calculations/[I mentioned in a post a couple of weeks ago] one of the main refactorings that we did was to move some calls to dependency methods from the constructor and into properties so that those calls would only be made if necessary.

After we'd done this the code looked a bit like this:

[source,csharp]
----

public abstract class ParentModel
{
	private readonly Dependency1 dependency1;

	...

	public decimal Field1 { get { return dependency1.Calculation1(); } }
	public decimal Field2 { get { return dependency1.Calculation2(); } }
}

public class BusinessProcess1Model : ParentModel { }
public class BusinessProcess2Model : ParentModel { }
public class BusinessProcess3Model : ParentModel { }
----

We wanted to ensure that the tests we had around this code made sure that the correct calls were made to 'depedency1' but because ParentModel is an abstract class the only way that we can do this is by testing one of its sub classes.

The question is *should we test this behaviour in each of the sub classes and therefore effectively test the same thing three times or do we just test it via one of the sub classes and assume that's enough?*

Neither of the options seems really great although if we cared only about behaviour then we would test each of the sub classes independently and forget that the abstract class even exists for testing purposes.

While the logic behind this argument is quite solid we would end up breaking 3 tests if we needed to refactor our code to call another method on that dependency for example.

I suppose that makes sense in a way since we have actually changed the behaviour of all those classes but it seems to me that we only really need to know from one failing test that we've broken something and anything beyond that is a bit wasteful.

In C# it's not actually possible for 'Field1' or 'Field2' to be overriden with an alternate implementation unless we defined those properties as 'virtual' on the 'ParentModel' which we haven't done.

We could however use the 'new' keyword to redefine what those properties do if the callee had a reference directly to the sub class instead of to the abstract class which means it is possible for a call to 'Field1' to not call 'dependency1' which means that maybe we do need to test each of them individually.

I'm not sure which approach I prefer, neither seems better than the other in my mind.
Scala: The '_=' mixed identifier
Date: 2009-09-14 23:49:07

I've been playing around with Scala a bit and in particular following some of the code examples from http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-5[Daniel Spiewak's 'Scala for Java Refugees' article on Traits and Types].

One thing that I got a bit confused about in one of the examples was the use of the '_' at the end of one of the function definitions:

[source,scala]
----

class MyContainer[T] {
  private var obj:T = null

  def value = obj
  def value_=(v:T) = obj = v
}

val cont = new MyContainer[String]
cont.value = "Daniel"

println(cont.value)
----

From my limited understanding of the language the '_' (or placeholder syntax) is often passed to functions when we only want to partially apply the function to its arguments but when you use it in that context there's usually a space between the function name and the '_' so it wasn't being used like that.

From http://www.artima.com/shop/programming_in_scala[Programming in Scala]:

____
Remember that you need to leave a space between the function name and the underscore, because otherwise the compiler will think you are referring to a different symbol, such as for example, a method named println_, which likely does not exist.
____

In this example we were able to make use of 'value' without using the '_' though so clearly this was some other syntax I was unaware of.

I came across the idea that it might be linked to 'http://www.scala-lang.org/docu/files/api/scala/util/DynamicVariable.html[DynamicVariable]' but I think that it's just a coincidence that 'DynamicVariable' happens to define a function called 'value_' since the code described above doesn't mention 'DynamicVariable' anywhere.

Eventually http://twitter.com/wgren/statuses/3979169229[Lars Westergren set me back on track by pointing out that what's being described is a mixed identifier] which is a much simpler explanation than what I'd been thinking!

In this case the mixed identifier is 'value_=' which defines an assignment operator which takes in a value 'v' of type 'T' and then assigns it to 'obj'.

It seems quite similar to the way we would use properties in C#.

I'm still finding having so many '=' on the same line to be a bit confusing at the moment so I'd  probably rewrite that function like this so it's easier for me to understand:

[source,scala]
----

def value_=(v:T) = { obj = v }
----

http://twitter.com/channingwalton[Channing Walton] also linked me to http://www.naildrivin5.com/scalatour/wiki_pages/ScalaProperties[a post which explains how Scala properties work].
TDD: It makes you question what you're doing
Date: 2009-09-25 23:48:33

My colleague Matt Dunn and I have been putting a lot of tests around some code over the last few days so that we can safely make some changes around that area and having finally created our safety net we've moved onto adding in the new functionality.

We're test driving the new bit of functionality whereas with the previous code only the code had been written with no unit tests and it's been quite interesting seeing the contrast in the style of code which seems to come out from these differing styles.

While we were writing the tests around the other code I found it quite surprising how often we came across code which wasn't actually needed - I guess if you only write the code then you need to make sure that all potential scenarios are covered even if it's impossible for them to happen.

In one case a null check was being done on a dependency of a class which always has its dependencies injected by a DI container and thus as far as I understand could never actually be null.

It seems to me that the outcome of this approach to coding can contribute greatly to what Fred Brooks coins 'Accidental Complexity' in 'http://www.markhneedham.com/blog/2009/04/11/the-mythical-man-month-book-review/[The Mythical Man Month]'  - extra code which makes the code base more difficult to read as a whole but which adds no value apart from that. Essentially waste.

When test driving code I find that the process of coming up with examples/tests before you write any code leads you to question how the system actually works.

For example Matt and I had thought that the new piece of functionality we were working on would need to make a call to a repository to retrieve some data since that's what was being done for the existing functionality.

However, while writing our tests it become quite clear that we wouldn't need to do that.

On this occasion we wrote a test with an expectation for a call on the repository, then wrote the code to make that test to pass before moving onto our test where we would assert that the values retrieved from the repository would be populated into the appropriate object.

It was at this stage that we realised that there was actually no need to make that call because we already had the data available to us from another source.

This has happened on quite a few occasions since and while I think pair programming helps put us in a state of mind where we are more inquisitive of the code being written, I think the TDD approach is quite useful as well.

I'm sure it's possible to avoid some of the problems I've described without a test driven approach but I certainly find it more difficult.
TDD: Asserting on test dependency code
Date: 2009-08-19 23:19:45

Something I've noticed a bit lately is tests which setup a load of dependencies for a test and then do assertions on that setup before getting on to calling the system under test.

The code tends to be similar to this:

[source,csharp]
----

public void ShouldHopefullyDoSomeAwesomeStuff()
{
	// setup via expectations for dependency1 and dependency2
	Assert.IsNotNull(dependency1.DependedOnMethod);	

	new SystemUnderTest(dependency1, dependency2).DoThatStuff();

	// test assertions
}
----

I've done this a fair few times myself and I used to believe that it actually made the test more valuable since we were ensuring that the dependencies were in a good state before we executed the test.

Looking at those types of assertions nowadays it feels like waste to me because we are basically testing our ability to setup the test correctly which is not the point of writing the test.

In addition tests written like this are more noisy and difficult to read for me at least as I find my eye is drawn to the assertions (and therefore typically to the end of the test) so having more than one block of these is a bit confusing.

If we're not sure that we've set up the dependency correctly then an alternative is to try and simplify the setup of that dependency so that it's really obvious that we've done it right.

There are a couple of ways that I've come across for doing this:

* Ensure that all the setup for the test is done inside the test and http://www.markhneedham.com/blog/2008/12/19/tdd-mock-expectations-in-setup/[not in setup methods].
* Extract away test data setup that we don't care about by making use of http://nat.truemesh.com/archives/000714.html[test data builders] where possible.

I've previously suggested that I found it quite useful to http://www.markhneedham.com/blog/2009/04/13/tdd-balancing-dryness-and-readability/[extract methods for groups/individual expectations/stub calls] but I think this may have inadvertently led to the above pattern since the code that we care about is now hidden a click away from where we need it.

I think I'd probably take the hit of having some duplication in tests instead of making the test more difficult to understand although like with all things there's definitely a trade off to make.
Builders hanging off class vs Builders in same namespace
Date: 2009-08-15 10:53:49

I wrote a couple of months ago about an approach we're using to help people find http://www.natpryce.com/articles/000714.html[test data builders] in our code base by http://www.markhneedham.com/blog/2009/06/02/coding-putting-code-where-people-can-find-it/[hanging those builders off a class called 'GetBuilderFor'] and I think it's worked reasonably well.

However, a couple of weeks ago my colleague http://luning12.blogbus.com/[Lu Ning] suggested another way to achieve our goal of allowing people to find the builders easily.

The approach he suggested is to put all of the builders in the same namespace, for example 'Builders', so that if someone wants to find out if a builder already exists they can just type 'Builders.' into the editor and then it will come up with a list of all the builders that exist.

The benefit of this approach is that it means we can make use of the http://www.markhneedham.com/blog/2009/02/16/c-object-initializer-and-the-horse-shoe/[object initializer] to setup test data  - perhaps one of the few occasions when it seems to be reasonably useful.

Lu Ning http://luning12.blogbus.com/logs/36477752.html[explains in more detail on his blog] but the idea is that instead of:

[source,csharp]
----

new FooBuilder().Bar("hello").Build();
----

We could do this:

[source,csharp]
----

new FooBuilder { Bar = "hello" }.Build();
----

The second approach requires less code since we can just create all public fields and setup a default value for each of them in the class definition and then override the values later if we want to as shown above.

We can't do this with the 'GetBuilderFor' approach since you can only make use of object initializer when you are initialising an object (as the name might suggest!).

Another advantage of this approach is that we don't have to write the boiler plate code to add each builder onto the 'GetBuilderFor' class so that others can find it.

The disadvantage is that once we type 'Builders.' to find the list of builders we then need to delete that text and type in 'new FooBuilder()...' which means the flow of creating test data isn't as smooth as with the 'GetBuilderFor' approach.

I don't feel like there is a really big difference between these approaches and as long as people can find code that's the main thing.

There would probably be less typing required with the namespace approach although I've never really felt that typing is the bottleneck in software development projects so it would be interesting to see if this would give us a gain or not.

We are still using the 'GetBuilderFor' approach on our project since there probably wouldn't be a massive gain by switching to the other approach at this stage.

It does seem like an interesting alternative to solving the same problem though.
F# Option Types
Date: 2009-01-02 22:35:31

I've been spending a bit of time working through the http://manning.com/petricek/[Real World Functional Programming] book to learn a bit about F# and one of the cool features I came across today (while reading http://blogs.msdn.com/chrsmith/archive/2008/07/10/mastering-f-lists.aspx[Chris Smith's post on F# lists]) is the Option type.

I first came across this idea a few months ago when discussing http://www.markhneedham.com/blog/2008/08/16/null-handling-strategies/[null handling strategies] with a http://markthomas.info/blog/[colleague] who pointed out that you could get around this problem in Scala by using the http://blog.danielwellman.com/2008/03/using-scalas-op.html[Option class].

From what I can tell this works pretty much the same way and solves the problem that we have when we want to perform an operation but don't know whether or not a value will be returned.

If a value is returned then we don't have a problem, but if not then we want a clean way of handling this.

One example of this is when trying to retrieve a value from a collection. When we try to get a value which doesn't exist this would typically throw an exception.

To give an F# example, trying to find the value 7 in a list from 1-5:

[source,text]
----

List.find (fun x -> x = 7) [1..5];;
----

This throws the following exception:

[source,text]
----

System.Collections.Generic.KeyNotFoundException: The item was not found in the collection
   at Microsoft.FSharp.Core.Operators.not_found[T]()
   at <StartupCode$FSI_0277>.$FSI_0277._main()
----

Luckily there is another way of trying to find this value:

[source,text]
----

List.tryfind (fun x -> x = 7) [1..5];;
----

[source,text]
----

val it : int option = None
----

Note that the type is now 'int option' with a value of 'None'. If we search for a value that does exist:

[source,text]
----

List.tryfind (fun x -> x = 3) [1..5];;
----

[source,text]
----

val it : int option = Some 3
----

We get a return value of 'Some 3'.

The beauty of this approach comes when pattern matching against these values. To give a contrived example:

[source,text]
----

let find value list =
    let option = List.tryfind(fun item -> item = value) list
    match option with
    | None -> printfn "Value %d not found" value
    | Some(valueFound) -> printfn "Found value: %d" valueFound;;
----

[source,text]
----

> find 1 [1..5];;
Found value: 1
val it : unit = ()
----

[source,text]
----

> find 6 [1..5];;
Value 6 not found
val it : unit = ()
----

I really like this idea and it seems cleaner than approaches I have used in C# and Java to achieve a similar outcome. I'm sure I'll come across more usages for it as my knowledge of F# increases.

Incidentally, Luis Diego Fallas has written a cool post showing http://langexplr.blogspot.com/2008/06/using-f-option-types-in-c.html[how to use option types in C#]. The syntax obviously isn't quite as clean as it is in F# but it still reads reasonably nicely.
YAGNI: Some thoughts
Date: 2009-01-17 21:01:38

If you hang around a team practicing http://www.extremeprogramming.org/[XP] for long enough, one of the phrases you are bound to hear is http://c2.com/xp/YouArentGonnaNeedIt.html[YAGNI] (You Ain't Gonna Need It).

Although it can sometimes be used to ignore things we don't want to focus on http://iancartwright.com/blog/2009/01/five-kinds-of-technical-debt.html[as Ian points out], in general the aim is to stop people from working on code that isn't currently required.

So assuming our team isn't being lazy and trying to avoid decisions that they don't want to think about, why do we hear the YAGNI call and more importantly, perhaps, what happens when we don't heed that call.

== Jack of all trades, master of none

One of the problems of writing APIs that are designed based on potential future use (by multiple clients) is that the *API ends up not being what any of the clients want* - it does its job but not in a way that makes life easy for any of the clients.

From my experience the easiest way to design usable APIs is to drive the design by using examples. We only write code if we have an example/test to drive that out.

At a higher level this means that we should drive the design of our code by working out how the client is going to use it rather than trying to anticipate how it might be used. This is sometimes known as http://www.code-magazine.com/article.aspx?quickid=0805061&page=2[client driven development as opposed to assumption driven development].

Joe Walnes' http://xstream.codehaus.org/[XStream] library is often referenced as an easy to use library because he only added features that he needed (as a client of the library) rather than trying to imagine what features people might want.

== Change becomes difficult

If we have driven our code based on assumptions of how we think it might be used in the future then it becomes more difficult to change it because we need to ensure that the changes we make won't cause problems for these potential future clients.

Code driven this way rather than by examples tends to be *much more complicated* because we don't know which cases we need to handle and which we don't - we end up trying to handle them all.

Making changes to code after it has been written is quite common but we have now made this more difficult for ourselves. Changes end up taking longer and we can't be sure that the change will work for anyone beyond our current clients anyway.

== Takes longer

When we only develop an API for clients that currently exist we are writing much less code than when we try to code for the generic case and therefore we can accomplish our task much more quickly. The inverse being that when we don't *we spend a lot of time* trying to write a solution that veers more and more towards being a framework.

This doesn't mean that we should completely tie our API to that client - instead we should ensure that our solution is flexible and easy to change in the future.
The danger of commenting out code
Date: 2009-01-17 16:02:33

An idea which is considered common sense by most developers but which is not always adhered to is that of not commenting out code.

Code is nearly always under source control anyway so commenting out code which is not being used doesn't really serve any positive purpose and it can have quite a few negative effects.

== Clutter

Ideally we should be able to read through the code without too much confusion - each method's name being descriptive enough that we can work out what is going on.

Having commented out code stops the flow of your eyes as you go down the code - *there is a distraction* and you want to know what it is.

Even more time is then wasted trying to work out why the code was commented out and whether it might still be useful or not.

== Misleading

Unless we trawl through the source control history it is difficult to know when and why a piece of code was commented out.

Sometimes when we discover a bug in our code we eventually end up debugging an area of the code which has some code commented out.

If that bug didn't previously exist then the natural thought is that perhaps commenting out that code is what caused the bug to appear. Clearly that is not always the case!

I have debugged code before which had parts commented out where uncommenting the code actually made the situation even worse.

Leaving uncommented code in seems fairly harmless but *it can waste quite a bit of time if someone misunderstands why it was commented out* in the first place.

== Broken Window Theory

The http://www.codinghorror.com/blog/archives/000052.html[Broken Window Theory] proposes the idea that if we do one bad thing in our code (i.e. break a window) then it becomes more likely that the next person who encounters that code will do something bad as well eventually leading to the *degeneration of the code*.

This is the same when commenting out code - if people see that there is code commented out then it becomes more acceptable for them to also comment out code and before you know it there are large chunks of code commented out and noone really knows why.

== So is commenting ever ok\...

I think commenting in the sense I describe here only really makes sense in the short term i.e. commenting out some code to see whether it is actually needed or not, running the tests, and then deleting it permanently if necessary.

If our aim is to produce expressive and easy to understand code then removing code when it is no longer needed can go a long way to helping us achieve this.
How does the user language fit in with the ubiquitous language?
Date: 2009-01-10 15:38:01

We've been doing some work this week around trying to ensure that we have a http://domaindrivendesign.org/discussion/messageboardarchive/UbiquitousLanguage.html[ubiquitous language] to describe aspects of the domain across the various different systems on my project.

It's not easy as there are several different teams involved but one thing we realised while working on the language is that the *language of the business is not the same as the language of the user*.

Although this is the first time that I recall working on a project where the language of the user is different to the language of the domain I'm sure there must be other domains where this is the case as well.

In our case the language is simplified so that it makes sense to the user - the terms used by the business make sense in that context but would be completely alien if we used it on the interfaces from which our users interact with the system.

At the moment our domain model represents the business terminology and then when we show the data to the user we refer to it by a different name. The problem with this approach is that there is a mental translation step in trying to remember which business term maps to which user term.

We can probably solve this problem somewhat by having the user terms represented in our Presentation Model but this still doesn't help remove the translation problem when it comes to discussions away from the code.

At the moment there aren't that many terms which differ but I'm not sure what the approach should be if there become more in the future, should we have a whole user language as well as a business specific ubiquitous one or should our ubiquitous language be the user language?