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) :)
This is how we do code review in my actual team:
Rules:
- No check-in without a code review (unless we paired on the task)
- Let the others know half an hour earlier that you might need a code review (so they can put up with the thought :D )
- 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
- 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:
- All files have to be Resharper green (unless of course you have a good valid reason to leave it orange)
- All tests have to pass
- Code review has to start with reading the stories that are affected by the pending code changes
- A good thing is to also have a look at the service and data contracts affected by the code changes
- 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)
- 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
- 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:
- We discuss stuff that we don’t agree until we come to a an agreed upon solution
- If we can not agree on something, we escalate the problem with the technical leader so he can decide what has to be done
- Whoever decided the changes, the reviewer, or the technical leader, the changes are always done
- 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!
I am for 7 years now in the IT industry I have heard a lot of good things about pair programming, I don't know if it is just a rumour :), like the fact that pair programming reduces the number of bugs by 30% , reduces the maintaience of the code, which is the largest part of a programme's lifecycle...
Well now I have the very exciting opportunity of working in an Agile driven development environment and I could peek a few advantages over this last two weeks.
First it was very, very easy for me to get into the project and become productive early, because I didn't have to stay by myself and dig into the application and worry about disturbing the other older team mates. Then, though I didn't have too much business knowledge I could make immediately myself useful as an assistant for the driving programmer, an OOP quality checker :) ...
Other things that I realized:
- there aren't really any dead times, you never end reading too much you email or start reding funny staff, because you can't let the other wait for you.
- many times when you just hear yourself saying loud an idea, you immediatly realize if something is wrong
- you never jump into writing code and this saves a lot of time and combined with test first driven programming and with the quality the programmers themselves, results in a high quality code.
So far it seems to me that the 2 programers working on a task would finish it earlyer than just one, I would say 1/3 of time earlyer, and the result is much better, meaning less bugs, more flexible code, so in the end you get to the result that there as a comparable amount of time spent on developing the task and a much smalller amount time for maintaining plus you have now two programmershaving deep knowledge about the task.
On a task you usually have the owner and the partner, so the partner can be changed, and moved in another pair after one day, and the owner stays on the task until it is ready. This changing of partners assures that everybody works with everybody and everybody gets a lot of knowledge on all the areas of the project. This is kind of Agile 
...
Too bad that a lot of managers don't realize the benefits and all that they can see is that they put two people on a task, instead of one which means waste of money for them.
A little piece of advice: if you're pair programming, always brush your teeth after eating and keep at hand lots of chewing gum and mints 
Here are the things that caught my attention in today's MSDN briefing:
A. Silverlight 2.0
1. You can use IsolatedStorageFile and IsolatedStorageSettings for storing data on the client machine, but they can be disabled by users, so this case must be treated appropriately
2. Xaml power toys http://karlshifflett.wordpress.com/xaml-power-toys/ , it is a VS 2008 SP1 addin that provide powerful code generating tools on context menus for Silverlight and WPF xaml developing
3. You can access HTML DOM Silverlight, which means that you can write C# code and manage Hml elements in C# code on the client http://silverlight.net/blogs/msnow/archive/2008/10/06/silverlight-tip-of-the-day-56-accessing-the-html-dom-from-silverlight.aspx
4. All web services calls can be done only asincronously , meaning that code has to have a certain shape to allow this (inline delegates definition on completed events… ) http://petesbloggerama.blogspot.com/2008/07/omg-silverlight-asynchronous-is-evil.html The reason is that Silverlight only runs on one tread and this kind of calls could cause browser freezing.
5. There is a Silveright for Sharepoint blueprint and some people are working on Moonlight (not Microsoft people, but some othera that collaborate with Ms to support Silverlight on Linux)
B. Unit testing in VS 2008 SP 1
6. UT
6.1 Private Methods can be tested (unlike in NUnit)
6.2 A unit testing project skeleton can be rapidly generated in a few clicks, one unit test per method (which simply calls the method tested)
6.3 After running the unit tests, a window appears, with results of the tests and the coverage degree, on double click on a method that doesn’t have 100% coverage, meaning that there are code paths that were not passed by UT, you are taken directly into the code and the lines of code that are not covered with UT, are highlighted in VS. This is pretty cool!
C. News or enhancements in VS 2008
7. Automated Build
7.1 A kind of Cruise Control implemented by Microsoft which is integrated in Visual Studio. It works with xml configurations files, but they can be modified using a graphic UI or directly in xml text (cool again J)
7.2 Team Foundation Server integrates with FxCop (static code analyzer) so that a policy can be set that no code can be committed until the code follows a set of rules specified in FxCop.
7.3 There is a .Net profiler (like the DotTrace of Jetbrains) – you run the application and than you have the execution times, hotpaths are highlighted, meaning calls that have the heaviest impact on the speed of the application.
D. DB Professional Visual Studio
8. Refactoring is very easy,
8.1 Renaming – you can change the name of a field , a table name , etc and VS knows to find all the places here this name is used and present them to you so you can chose to replace it everywhere or select the places where you want it replaced …
8.2 There is a wild card expansion option in the context menu, it replaces * with the expanded fields list from a table
9. You can generate unit tests for the database stored procedure within your db project
10. You can compare either a db project and an existing database or 2 db projects or 2 existing databases, within VS.
11. Powerful data generation tools, you can specify column generation patterns from simple ones, like a random list of values provided in a table, distribution percent for a specified list of values, regular expressions for generated values or some more complex generating functions, that you can develop in C# .
12. You can generate load tests.
Nowdays I am in charge of database optimization on our project.
First I needed to see what the problem was, second resolve them.
So I set on a profiler in Sql Profiler. Being overmotivated I added lots of events to trace which resulted in a table with very many columns. I also did another evil thing, I set the trace to roll at 20M. This resulted in 98 trace files 
.
I tried to find some way to import them in SqlServer, but the SqlProfiler interface only allowed 1 trace file at one time to be saved as an sql table.
Well, it was hell, so I gave up importing them one by one and started to Google for a way to concatenate the SqlProfiler trace files, and here's the Golden code line :
SELECT * INTO trace_table
FROM ::fn_trace_gettable('c:\my_trace.trc', default)
You can read more about it here http://support.microsoft.com/kb/270599 .
The point is there was nothing inn the above link to mention that this line achieves this as well,so the surprise was a pleasant one.