Have you ever wanted to rename a namespace but you have too many classes in the namespace that it would be an infeasible hassle changing all of them individually. Even using a tool like ReSharper to refactor the namespaces class by class is a hassle. I'm gonna show how to rename a namespace for all of its classes in a couple of key strokes using ReSharper.

Example

Mechanics

1. Open Class View (Ctrl + Shift + C)
2. Choose the namespace you want to rename
3. Press Ctrl + R, R*
4. Pick another name
5. Hit Next

and you're done!

Please leave a comment if you found this useful.

* Visual Studio scheme

1. Abstract 
2. Refactoring
3. Test coverage 

Proceeding with a solution there is no way of changing the implementation of the GregorianCalendar class to get the correct behavior so we have to go about this another way. One is to subclass the GregorianCalendar and override the GetWeekOfYear method. Another is to implement the GetWeekOfYear in a class totally separate from the .NET framework. I think that the first one is the way to go since the error that we're trying to correct is in the framework itself.

So, first we alter the help method in the test case to use our sub classed IsoCalendar (which we haven't written yet).

So, we are not in a compile state yet so lets do the simplest thing to get this running. I decided to subclass the GregorianCalendar class since what is wrong is the GetWeekOfYTear method of that class. I basically override that method like below.

We run the test a get a red bar. Fine, but now lets go ahead and implement the algorithm. However, this has been done over and over with varying elegantness. My favorite is the work of programmer and mathematician Julian Bucknall. His original implementation can be found at his blog. So, instead of returning -1 I call the GetIsoWeek method from Bucknall's implementation and take the modulus of 100 (since the result from the algorithm is of the form YYYYWW). We run the test and we get a green bar!

 

Now when we get a green bar there's just one more thing to add. The ISO 8601 week should only be returned when the parameters rule and firstDayOfWeek is set properly according to the documentation. In all other cases the GregorianCalendar implementation works just fine. We fix this with a guard clause at the top and we're done.

Summary

During this series we covered test coverage for the faulty implementation of weeks according to ISO 8601. We used Test-Driven Development to provide a fix using Julian Bucknall's really smart implementation. Next we should take a look at refactoring to design patterns.

1. Abstract
2. Refactoring

Our task at hand is to get as much coverage as possible when it comes to errors in the implementation. The ideal coverage is one where all dates are tested. The problem is that the number of dates is infinite. This is of course always a an issue when testing software but it may be more obvious here. If we test all dates there will we a great deal of dates that we know are correct. It should suffice to test only the dates that are incorrect. However, this number is also infinite. We will have to limit our coverage but still get as much breadth as possible. Basically we need to get back to the definition.

According to the ISO standard, in the period 4 January - 28 December the week number is always the same as the Gregorian week and the same also apply for all Thursdays. Thus, the mentioned dates can be safely excluded in our test coverage. Though we still have an infinite number of dates to cover, we are getting there. Finally, we can limit our test coverage to a set of years that can be reasonable argued to appear in the application which we are implementing.

To simplify it the resulting dates are non Thursdays 1-3 January and 29-31 December every year from 2005 - 2015.

Using the calendar in Outlook I compile a matrix of the week numbers in the year interval. The dates that are grayed are Thursdays which should not be part of the test.

	01-jan	02-jan	03-jan	29-dec	30-dec	31-dec
2005	53	53	1	52	52	52
2006	52	1	1	52	52	52
2007	1	1	1	52	52	1
2008	1	1	1	1	1	1
2009	1	1	1	53	53	53
2010	53	53	53	52	52	52
2011	52	52	1	52	52	52
2012	52	1	1	52	52	53
2013	1	1	1	52	1	1
2014	1	1	1	1	1	1
2015	1	1	1	53	53	53

The matrix can be thought of as a set of { date, week number } pairs which can easily be implemented in code.

I create a test which iterates over the set and makes assertions that the correct week was generated by the calendar. It turns out however, that only eleven of the dates generate a wrong week number. I refactor the code to only include the weeks that are wrong. I get a red bar and I see another opportunity for refactoring, the previous two tests can be integrated with this test by just adding the date - week pair to the set. The following is the resulting test:

 

Now that we have a test that fails we can come up with a solution to get the test to pass.

Abstract

So, now we make up another test. Looking at the calendar we see that new years eave 2001 should also belong to the first week of 2002 according to ISO 8601. We write the test much like the previous test and we get another red bar. Now its time to refactor. We need to remove the duplicated code in the two tests. First we start with extract method which results in the following method: 

 

 

Now, we can refactor the tests using the new method like this:

We still get two red bars thus we can be insured that we haven't changed any functionality. The next step should be to come up with another test to get more coverage of the errors in the implementation.

The implementation of weeks according to ISO 8601 (used e.g. in Sweden) is faulty in .NET Framework. In particular the GregorianCalendar and CultureInfo classes are faulty when it comes to ISO 8601.

So, how do we know that the implementation of ISO 8601 is faulty using TDD? We come up with a test that fails. By the ISO definition the first week is the week with the year's first Thursday in it. So, we know that e.g. 2003-12-31 is actually week number 01 of 2004 since it is a Wednesday and thus belongs to the first week. The following is a first attempt at a test:

 

Now we get a red bar and we know that the implementation is flawed. However, this is only a single test. If we get a green bar, is the implementation correct? No, of cource not. We need to write more tests to be sure.