marocanu2001

We used MsTest framework for a project that mainly had integration tests for Wcf Services, and found particularly useful to use AssemblyInitialise method to start the services hosts before all the tests are run and AssemblyCleanup to stop all the hosts after all the tests in the assembly have run.

At some point, the company decided they would like to change this project to use NUnit instead of MsTest (for sake of uniformity, as all thi other project were using NUnit).

The only problem that I saw there was that I didn't find any easy way to simulate this AssemblyInitialise and AssemblyCleanup methods.

But here we are saved, as someone told me about this SetupFixture which works like this:

The class with this attribute can contain a SetUp method and a TearDown method.
The setup method from the Setup fixture  is executed before all the tests from a namespace are executed, TearDown method, after all the tests in a namespace are executed.

This was very useful for out DB integration tests as well, as we needed to setup database stuff before executing all the DB integration tests.

So here we are, saved and NUnit is still better than MsTest ! (but not better than MbUnit , imho) :)

• Share This Post:
• 
• 
• 

Posted On Thursday, November 19, 2009 8:13 AM | Feedback (1)

This is how we do code review in my actual team:

Rules:

1. No check-in without a code review (unless we paired on the task)
2. Let the others know half an hour earlier that you might need a code review (so they can put up with the thought :D )
3. Try to change the reviewer as often as possible, so you should not care that the person who reviews you is in blue or red team
4. Try to code review small amount of code, as it is easier (and this relates to another rule that we try to follow, no to leave code unchecked in over night)

Code review steps:

1. All files have to be Resharper green (unless of course you have a good valid reason to leave it orange)
2. All tests have to pass
3. Code review has to start with reading the stories that are affected by the pending code changes
4. A good thing is to also have a look at the service and data contracts affected by the code changes
5. Take the pending changes files and go through them one by one reviewing the changes line by line (even the csproject and solution files, as it might reveal forgotten unwanted references)
6. Simple things that come up in the code review can be fixed on the spot, if the reviewer is not too busy and you have enough time allocated to the code review task
7. If things that are rather complex changes come up, then the code review should be interrupted, and doe again when the changes are done.

Other unwritten rules that we follow:

1. We discuss stuff that we don’t agree until we come to a an agreed upon solution
2. If we can not agree on something, we escalate the problem with the technical leader so he can decide what has to be done
3. Whoever decided the changes, the reviewer, or the technical leader, the changes are always done
4. We don’t have a code guidelines document, so the code review relates a lot to the knowledge in the team and the known convention (lot of them discovered in the code reviews actually J )

On thing that I find handy is if the reviewer does not have enough time to attend my changes during the code review, I write in code TODOs comments with the code reviews observation which I fix before checking in.

There are several really good things that come out of code review:

-          sharing the business logic, knowledge,

-          spotting business logic problems,

-          neat code,

-          learning from the other people in the team in an informal way,

-          Reduce bugs found in testing

-          Become better friends!

• Share This Post:
• 
• 
• 

Posted On Thursday, November 05, 2009 10:27 AM | Feedback (0)