Could not find default endpoint element that references contract ‘[project]’ in the ServiceModel client configuration section.

So, I was tasked with testing a WCF service that publishes an interface for our customers to insert stuff into our database. The WCF service is an integrator and the functions allow customers to add their data in a controlled way without having to go through our main application. It’s quite useful as they can basically add data from any source they like and it is then correctly inserted and can be viewed in the main application.

We just had a new release and we changed how time is stored in the database. We went from local time to UTC. This is quite a major change but the users shouldn’t need to be aware of it. I made the changes to this WCF service and then it was supposed to be tested. That testing was never done and I got tasked with doing it, ASAP, it should be finished yesterday, get to work!

Anyway, started fiddling with nUnit to do integration testing.
Wrote a test, compile fine and went on to run the test in nUnit when I’m greeted by the following message:

(TestFixtureSetUp): SetUp : System.InvalidOperationException : Could not find default endpoint element that references contract 'NIS.TicketIntegrationServiceSoap' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.

After looking through app.config and it’s various locations I get the tip from a colleague to try associating dlls to nUnit and double click on it. Voila! Worked perfectly.

My friend told me that this has to do with working directory for nUnit. It seems this issue has been around for quite a while and is not yet resolved.

Read Full Post »

Microsoft PowerPoint vs S5 HTML slide system

A while ago I spoke with my friend and he inspired me to do a tech-talk here at work. There were no tech-talks or any such activity here so I decided to go speak to my boss, who incidentally was new and seems to want to change some things, and almost before I could get my question out he said “Go for it!”.

I had already decide on a topic so the next thing was to decide how to make the slides that I’ll use.

I had previously worked a little with PowerPoint and though it’s good I didn’t quite like it. My friend gave me a tip of S5 which he had used and liked a lot.

I decided to try it out and found I liked it as well. Why? Well, that’s what the post is about. A small comparison between PowerPoint and S5.

First out is PowerPoint.

PowerPoint:

• is quicker to create presentations in
• has a better support for presentations
• works better if you want to use slideshare
• works better if you want to send your presentation to someone without putting it on a public address.
• is not shown differently in different “browsers”
• has official support (since it’s a purchased application)

And now for S5.
S5:

• is open source
• is more easily manipulated
• requires knowledge in atleast HTML and preferably CSS
• can be put on a webpage and run from there
• only thing needed on the computer to run the show is a browser
• can be souce controlled (since it’s only text)

On a personal level I don’t like the drag-and-drop way of doing it that PowerPoint uses. I like seeing the code that’s behind. I guess it comes from being a developer.

So, to summarize the comparison:

If you have the time and the knowledge of html and css and want to try something new, go with S5.
If you want massive support and tutorials and need to get a presentation very quickly, go with PowerPoint.

A small note is that once you’ve fixed the look of your presentation in S5 you can reuse it in the next presentation you do, greatly cutting down the time. This is of course only applicable if you want the exact same look.

Read Full Post »

Unit testing in Ruby using Unit::Test, a learning process. Part 2

In part two I’ll keep testing the prime? method and then I’ll make a new method that uses the same algorithm and that way show some refactoring.

Let’s start by checking for faulty input. A prime number can’t be negative so there’s no use checking for primes in values below zero. It might seem harsh but I decided to throw an exception when the user tries to input a negative number into my prime method. For this I’ll use the ArgumentError that comes with standard Ruby. I could create my own NegativeArgumentError (which is quite easy) if I wanted but that’s beside the focus of this post.

So, as usual I start with writing the test first.

def test_negative_input_to_prime_raises_exception
    assert_raises(ArgumentError) {@primality_tester.prime?(-2)}
end

Here I tell the framework that I am expecting the function to raise an exception by the name ArgumentError when I send in a negative value.

Running this I get a failed test. ArgumentError is not thrown, instead a DomainError is thrown from the sqrt-function (if you know your math you know that you can’t do the square root of negative values unless you use complex numbers). We’ve reached the red phase, test fails. Now, let’s make it pass.

Ok, simplest solution first.

def prime?(num)
    raise ArgumentError if num == -2
    
    # More code here
  end
end

Run tests and they pass.
Ok, next test, another negative number. Let’s say -23.
Tests fail.
And now I’ll make sure to plug that hole.

def prime?(num)
    raise ArgumentError if num > 0
    
    # More code here
  end
end

Tests pass.
Do I need to test more negative numbers? No, not really. I know that I got the > right as it takes negative numbers and not positive and there’s no real edge cases to test (not entirely true, zero would be an edge case but I’ll test zero later) so I’ll be happy and done with negative numbers.

And finally there’s a few edge cases aswell that I want to test. These being 1 and 0. Per definition 1 is not prime eventhough it can only be divided by 1 and itself. Let’s make sure 1 is not considered prime.

Test first and make sure it fails.

def test_1_is_not_detected_as_prime
    refute( @primality_tester.prime?(1), "1 should not be considered prime")
end

Let’s make it pass now.

def prime?(num)
  raise ArgumentError if num < 0
  return true if num == 2
  return false if num % 2 == 0 or num == 1

  # More code after this
end

For the observant of you, you’ll notice that I did a small refactoring here.
Before I returned true if num % 2 was not zero. Now I changed that into returning false if num % 2 is zero, I also tacked on 1 at the end. All my tests pass so the refactor did not break anything.

And the last test on the prime? method. 0. 0 is not prime and should thus return false.

When I run the test for 0 I get pass from the start, no failed test there. Why? Well, let’s look at the code again.

def prime?(num)
  raise ArgumentError if num < 0
  return true if num == 2
  return false if num % 2 == 0 or num == 1

  # More code here
end

0 divided by 2 is 0. So our case of 0 is caught by line 4 already. Alright, since I could verify that so easily I’ll not make it fail before I again make it pass.

Am I done?
Not quite. Now I know that the function detects primes fine, it raises an exception for negative input and the edge cases 0 and 1 are not considered prime. But, what about non primes, does it really return false for non primes? For all even it does but what about 9, 15, 21, 51? I’ll make a test covering that aswell. To make sure even are not detected prime I’ll also put 4 in the list.

[4, 9, 15, 21, 51].each do |p|
  define_method :"test_that_#{p}_is_not_detected_as_prime" do
    refute( @primality_tester.prime?(p), "Expected false, got true")
  end
end

And those tests pass aswell.

Are there any more tests that could be done here? There might be a few but I’m quite happy with the ones that are already in there. Now I know that the function raises exceptions for negative input, that it gives me correct answers for values prime and not prime, and I’ve tested the edge cases.

Read Full Post »

Unit testing in Ruby using Unit::Test, a learning process. Part 1.5

So, to continue* the series lets keep working on the prime calculator.

* – I asked a question on stackoverflow yesterday and got some good tips. It also seems that I did not follow The Ruby Way of writing and did not really follow the DAMP-principle. So, I’ll do a small recap and explain the points that were made in the answer to my question. Read the previous post for more on DRY and DAMP principles.

I’ll do a small recap of last post showing the changes that were proposed and what they mean.

The proposed changes was this:

Instead of having one test function for each test case we can loop over the values we want to test.

def test_that_the_first_few_primes_are_detected_as_prime
  [2, 3, 5, 7, 11, 13, 17].each do |p|
    assert( @primality_tester.prime?(p), "expected true, received false" )
  end
end

The result is not optimal from my point of view:

F:\temp>ruby test\test_prime_calculator.rb
Loaded suite test/test_prime_calculator
Started
....F.
Finished in 0.002001 seconds.

  1) Failure:
test_that_the_first_few_primes_are_detected_as_prime(TestPrimeCalculator) [test/test_prime_calculator.rb:41]:
Expected true, got false

6 tests, 11 assertions, 1 failures, 0 errors, 0 skips

Test run options: --seed 18437

As you can see there are no indications of what went wrong. We have no idea which number was not prime.

Enter second method:

[2, 3, 5, 7, 11, 13, 17].each do |p|
  define_method :"test_that_#{p}_is_detected_as_prime" do
    assert( @primality_tester.prime?(p), "expected true, received false" )
  end
end

So, we get into the hardcore stuff and do some meta programming. Here we loop over the prime numbers we want to test and define a function for each of them. The failure message is much better. Now we know that 2 was not returned as a prime.
This might seem a little overkill for the problem that we want to solve.

  1) Failure:
test_that_2_is_detected_as_prime(TestPrimeCalculator) [test/test_prime_calculator.rb:47]:
Expected true, got false

Maybe the best was to keep the way of testing that we had when we started (just some refactoring, using assert and changing the names a little):

def test_that_2_is_detected_as_prime
  assert @primality_tester.prime?(2)
end

def test_that_3_is_detected_as_prime
  assert @primality_tester.prime?(3)
end

def test_that_5_is_detected_as_prime
  assert @primality_tester.prime?(5)
end

Or we could make it even more compact:

def test_that_the_first_few_primes_are_detected_as_prime
  assert @primality_tester.prime?(2)
  assert @primality_tester.prime?(3)
  assert @primality_tester.prime?(5)
end

I’m not really happy with the last way however. My suggestion would be the meta-programming way of defining functions as the tests run or if the tests are very simple then doing a separate function for each input to test. That can be structured into other files if we don’t want the clutter that comes from it. That file holds all the tests for checking valid prime numbers.

Read Full Post »

DRY and DAMP principles when developing and unit testing.

There are a few important principles to follow when writing code. The one I will talk about today is the DRY principle. DRY stands for Don’t Repeat Yourself. What does that mean in code then? Basically it means that you should never duplicate code. If you do the same thing in two different places then break that functionality out into a function.

Why you might wonder?

Consider this:
You have three places where the exact code is used and you realize that you want to do something subtly different. So you go about changing the code. But, you forget to change the code in one place. You go on coding and then the test section tells you that “the results are inconsistent, in places XXX, YYY happens but in place ZZZ, AAA happens”. This might be hard to find later. Besides, when you want to change anything you have to do it in multiple places.

A real life example of this that I quite recently encountered in a project I took over:

dateCreated.ToString("yyyy-MM-dd HH:mm")

That line was scattered all over the place. It also turned out that the hours (HH) was written as 12 hour clock in some places and 24 hour clock in others. A very simple thing, hh (12 hours) instead of HH (24 hours). It still took me a while to track that down as everything looked fine (I also didn’t catch on to the small/capital letters until after a while). What I did was breaking the string out into a function like so:

private string GetDateFormat()
{
    return "yyyy-MM-dd HH:mm";
}

and then used like this:

dateCreated.ToString(GetDateFormat())

Yes, I realize that this could be made in a lot of other ways, this sufficed for me though.

So, the benefit here is that I can change in one place instead of a lot, it also gets easier to read.

This was a very simple example but I think it shows pretty well the point I try to make. When developing new code, always try to follow the DRY principle.

What about the DAMP principle then?
DAMP stands for “descriptive and meaningful phrases” and is the opposite of DRY, not in the sense that it says “everything should look like a trash heap and be impossible to read”, in that readability is more important than avoiding redundant code.

What does this mean and where to use it?
DAMP mostly applies when writing test code. Test code should be very easy to understand to the point that some redundancy is acceptable.

In my previous blogpost I showed how to unit test in Ruby using Test::Unit and I had the following code:

def test_2_inserted_return_true
    prime_generator = PrimeCalc.new
    actual = prime_generator.is_prime?(2)
    assert_equal(true, actual)
  end
  
  def test_7_inserted_return_true
    prime_generator = PrimeCalc.new
    actual = prime_generator.is_prime?(7)
    assert_equal(true, actual)
  end
  
  def test_13_inserted_return_true
    prime_generator = PrimeCalc.new
    actual = prime_generator.is_prime?(13)
    assert_equal(true, actual)
  end

There are a few ways of doing this that is more DRY which I’ll show you first.

def test_that_the_first_few_primes_are_detected_as_prime
  [2, 3, 5, 7, 11, 13, 17].each do |p|
    assert @primality_tester.prime?(p)
  end
end

Since there is no real difference in what is tested (except that the input value should be different) we could do this. A loop that asserts that the values inserted are prime.

The question is which is more descriptive of the above and the below however. It depends on the number of values to be tested I’d say.

def test_that_2_is_detected_as_prime
  assert @primality_tester.prime?(2)
end

def test_that_7_is_detected_as_prime
  assert @primality_tester.prime?(7)
end

def test_that_13_is_detected_as_prime
  assert @primality_tester.prime?(13)
end

Note: There has been a few refactorings made as you can see. The class is created in the setup part, we do the method call in the assert and since we want to check truth values assert is used instead as it passes if it receives true.

Read Full Post »

Unit testing in Ruby using Unit::Test, a learning process. Part 1

I quite recently started unit testing and as a first stop I played a bit with Ruby and Unit::Test as those are so easy to get going with. In C# you have to download nUnit and configure that, set up a lot of projects and references. Now, I’m not saying that is hard – I’m just saying that it’s easier and quicker to do it in Ruby.

The other motivation was that I decided I will start Ruby with Test Driven Development so I get into it at the get go.

So, lets get started with a few details about my environment:

• Ruby 1.9.2
• Windows 7

Right, lets kick this off by making a prime number calculator. We’ll start with creating both the application and the test files and create the classes.

class PrimeCalc
end

And the testfile

require_relative "../lib/prime_calc.rb"
require "test/unit"

class TestPrimeCalc < Test::Unit::TestCase
end

Nothing too wierd here. In the testfile I require the application file and the test::unit-framework.

So, true to the doctrins of TDD a test is the first starting point.
I want my prime calculator to be able to determine if a number is a prime number or not. An appropriate name would be is_prime? I think.

The test will check to see if 2 is prime.

require_relative "../lib/prime_calc.rb"
require "test/unit"

class TestPrimeCalc < Test::Unit::TestCase
  def test_2_inserted_return_true
    prime_generator = PrimeCalc.new
    actual = prime_generator.is_prime?(2)
    assert_equal(true, actual)
  end
end

And the source code only defines the function (so there’s no runtime error on missing method).

class PrimeCalc
  def is_prime?(num)
  end
end

The test fails and the “Red”-phase in TDD is reached.
See test result below:

F:\temp\> ruby test\test_prime_calc.rb
Loaded suite test/test_prime_calc
Started
F
Finished in 0.003500 seconds.

  1) Failure:
test_2_inserted_return_true(TestPrimeCalc) [test/test_prime_calc.rb:9]:
<true> expected but was
<nil>.

1 tests, 1 assertions, 1 failures, 0 errors, 0 skips

Test run options: --seed 32146

As we can see it expects true to be returned but it gets nil back (if you don’t know why this is; look up return values on methods in Ruby).

So now it’s time for the “green”-phase of TDD. Making the test pass with as little effort as possible. In this case I just let the class return true if 2 is provided, thus.

class PrimeCalc
  def is_prime?(num)
    return true if num == 2
  end
end

And the test passes. Nothing to refactor so let’s go on.

A note is probably in order here: This seems very silly. If 2 is provided then true is returned. Minimum effort to pass the test. Let’s think about this again. Why do more work than needed. If I start doing a whole lot of cases then it’s very easy to introduce bugs or do things that will never be used and just create noise. Alright, onward!

To add some flesh to the actual prime algorith I add a few more test cases. They look exactly the same as the one where 2 was sent in but this time I send in 7.

So, prime theory says that a number is only prime if it can be divided by 1 and itself and no other numbers. From this we can draw the conclusion that any multiple of 2 will never be prime.

First the red-phase. Run the tests and there will be one passing (2) and one failing (7).

Time to fix the failing test. Remember: minimum effort to go to green. In this case I will use the fact that no even numbers can be prime.

class PrimeCalc
  def is_prime?(num)
    return true if num % 2 != 0
  end
end

And run tests again.
One passing and one failing. But, this is wrong. The first test failed, 2 is prime but the method returns false. Not to worry, this one of the benefits of unit testing. Code can be changed and verification is quickly recieved. Here I say that no even numbers can be prime but 2 is even and prime. Let’s change and make sure that 2 returns true.

class PrimeCalc
  def is_prime?(num)
    return true if num == 2
    return true if num % 2 != 0
  end
end

Run unit tests and feel the excitement of all tests passing. However, let’s not rest on our laurels. There’s a lot of cases that aren’t checked. Besides, not all odd numbers are primes. Another test where 13 is used as input. Run tests and have the new test fail. Change the code to pass that test.

Here I do some optimization by not counting higher than the square root of the number itself. Prime theory says that if a factor hasn’t been found before the square root of the number is reached, then no factor will be found (apart from the number itself). Require mathn to get the sqrt method. 2 is already checked so start at 3 and start dividing the number, if a factor is found then the number isn’t prime. If no factor has been found when the loop ends then return true.

class PrimeCalc
  def is_prime?(num)
    return true if num == 2
    return true if num % 2 != 0

    i = 3
    for i in 3..Math.sqrt(num).ceil
      return false if num % i == 0
    end
 
  return true

  end
end

Run tests and see them pass. Nothing to refactor here. Or is there? Let’s take a look at the test code again.

class TestPrimeCalc < Test::Unit::TestCase

  def test_2_inserted_return_true
    prime_generator = PrimeCalc.new
    actual = prime_generator.is_prime?(2)
    assert_equal(true, actual)
  end
  
  def test_7_inserted_return_true
    prime_generator = PrimeCalc.new
    actual = prime_generator.is_prime?(7)
    assert_equal(true, actual)
  end
  
  def test_13_inserted_return_true
    prime_generator = PrimeCalc.new
    actual = prime_generator.is_prime?(13)
    assert_equal(true, actual)
  end

end

See how the line prime_generator = PrimeCalc.new is repeated in all tests? This does not follow the DRY-principle (Don’t repeat yourself). Let’s refactor that using the test frameword method setup and move the offending line in there. Setup is a method that is run before each test.

def setup
    prime_generator = PrimeCalc.new
end

Now we have a prime calculator that can return (with a decent certainty) an answer if a number is prime or not. Are we done? No, not yet. But the post is already long enough so I’ll continue in part 2.

Read Full Post »

The Art of Unit Testing by Roy Osherove

So, I recently decided that I would really start to get into unit testing and try out Test Driven Development. Where to start?

Personally I have trouble picking something up that I have no clue about. I can’t just sit down and start fiddling around with nUnit, or similar frameworks for unit testing, without quickly loosing motivation. It is very discouraging to know something should be possible but not know how, search on the net how to do it and then the next line run into the same issue. After a while I loose heart and then motivation gets shot down quickly after that.

I also find it quite hard to get best practices and all that knowledge about how things work from searching the internet. I like to be taken through the subject at a measured pace with a plan in mind.

In comes The Art of Unit Testing.

For a complete novice or for someone who has never worked with Unit Testing but knows some of the theory this is a good book to start with. For someone who has worked with unit tests and has a good grasp of unit testing this book is probably a bit basic even though I guess it could be a good way to review your skills.

The book takes it slowly from the start and builds all the way up to advanced concepts such as mocks, constructor injection and when to use stubs or mocks. It also gives tips on how to get a company to start using unit testing and a short chapter on how to get legacy code under test. It also lists the more important of the frameworks that are used with unit testing, such as testing frameworks, test coverage tools, dependency finder tools etc.

The book focuses on .net and primarily the nUnit-framework but people using other languages benefit from the techniques as these are usually applicable no matter what language is used.

A good and comprehensive read for those who are new to unit testing and a good review of skills for the experienced.

Read Full Post »