Effective C # Principle 48: Learn more about tools and resources

For C # as well. NET, this is an exciting time. These tools are now relatively new and the entire community is learning how to use them. Some resources can help you improve your knowledge as well as for. NET and C # to create a larger knowledge community. These are the tools I recommend to C # developers every day. All the content about C # practice is still in writing, follow them and keep abreast of the relevant content.

The first tool to be used in each C # Developer's toolbox is NUnit, which can be found on the www.nunit.org Web site. NUnit is a tool that automates unit testing, and features similar to JUnit's. Like most other developers, I hate writing test code and testing it myself. NUnit makes these processes very efficient, and when you use them regularly, you're guaranteed to be used to testing all of your C # classes. Whenever I create a class library project, I add a NUnit test project and add the automatically generated tests as part of it. I add a configuration to create and run tests, which can be tested at every compile time. Then, I can convert the configuration of the activity to control whether or not to make the unit test a part of the regular program. By default, I run them. When I need a UI test, I switch to another configuration.

When using NUnit, you can learn some interesting techniques by detecting NUnit's source code. NUnit uses some advanced reflection habits to load and test your assembly. It uses attributes to find test packages, test cases, and expected results for each test case (see Principle 42). This is a very good example of how you can use these techniques to create a tool that you can configure dynamically, and it can be widely used.

Next up is FxCop, a free tool that can be obtained from GotDotNet (www.gotdotnet.com). FXCop analyzes the IL in your assembly to see if it violates the principles of practice and where it reports the violations. Each principle has a reliable metric, and the reason for using this principle. As with all the recommended principles in this book, some documents have a brief justification for a particular principle. You can determine whether these practical issues comply with these recommendations. You can also configure whether to apply each principle to the project. I don't agree with some of the principles of FxCop, and I have explained the reasons in front of this book. However, like NUnit, FXCop can be part of the formal process you create. After each compilation, you can have a compile-time step, you can use FxCop to analyze the principles you choose. Figure 6.1 shows an example of an output from a FxCop. Although some of the recommendations are not my favorite (for example, there is one that makes every assembly supposed to be COM-see), it's really a useful tool because it lets you think a lot about the decisions you've made by default.

Figure 6.1,FXCOP Analysis of an item:

Figure 6.1. FXCop analyzing a project.

[View full size image]