ISerializable - Roy Osherove's Blog

Agreed. Or you could just implement the reflection yourself, it isn't that hard. That does not address the brittleness in your tests, though.

One other interesting approach I've seen with TDD is to make all the "significant" methods public so they can be exposed to the test classes, but then define separate interfaces to be the contract external callers use. This way you get easier testability by not having to go through a wrapper/reflection while at the same time still retaining some control on which methods external objects can call. In terms of "significant" methods -- they would be those that had enough complexity behind them that you feel they warrant their own test case. It also requires thinking about the interface separate from the class itself which might be considered an added benefit.

Scott: Nice idea.

Hello everyone, I'm the dev for this feature, and I just wanted to clarify a few points on this issue.

First of all, the generated tests will only use those wrapper classes (officially, we call them "private accessors") if the class being tested is non-public, or if you selected a non-public member to test. If your class is public, then the "target" variable in the generated test method will be an instance of the type being tested. If it's not public, then we'll use the first public type in its inheritance hierarchy. If the class is public but the member we need to invoke is private, then we'll still declare target as your type, and then we'll create a separate variable to store an accessor created from the target, and invoke the member on *that*.

To sum up, if your type is public, there will always be a variable of that type in the generated test, and if you use Generate Method Stub on it, then the method will be generated in the expected place. We expect people who use private accessors in their hand-written tests to follow the same pattern. Unfortunately, it's unlikely that we'll be able to forward refactoring operations on private accessors to the code under test, or vice versa (so that if you Reorder Parameters on your code-under-test, for example, your test code that uses a private accessor will be fixed up as well). For now, we attempt to mitigate the problem by using private accessors only where necessary -- public members don't show up on private accessors (unless the type itself is private, in which case it's not really a public member to begin with), so all the refactoring features should simply work as expected for public things (even if we have to call a private constructor to create the object, we still declare the variable as the public type and only use the accessor to call the constructor itself), and you can't get cross-project refactoring on non-public members today anyway because they're not exposed to other projects, so you're not really "losing" anything by using the private accessors. That said, we would love to implement this feature, and it's definitely on the list of features to investigate for the next version.

We've also done a lot of thinking about the brittleness of private accessors. We plan to investigate a feature for this version that will result in private accessors being automatically updated as your code changes (or at least when you compile, the actual details aren't finalized yet). This means that, while refactoring still won't work for private methods (see above comment about how it doesn't work today in that situation anyway), at least you'll get meaningful compile errors when your private methods change, which you can then fix normally. The plans for this change are still tentative and we're not sure yet if it will be doable, but every customer that asks for this feature makes it more likely to happen, so please send in your vote on whether you think this would be useful.

We really appreciate the feedback. Thank you!

知道.net下有个NUnit，一直没有用它来写程序。今天测试了下试试,写点心得出来,一边写程序一边还得测试，浪费了很多时间精力。代码有了一定规模了，慢慢体会到单元测试的作用。用Nunit进行单元测试能及时发现新的Bug,保证原有的功能正常运行。而不必手工一个个的去试验,这是很宝贵的。在NUnit的安装目录的bin下面有两个config文件:nunit-gui.exe.config，nunit-console.exe.config，其中有一段startup的配置段，默认如下:

知道.net下有个NUnit，一直没有用它来写程序。今天测试了下试试,写点心得出来,一边写程序一边还得测试，浪费了很多时间精力。代码有了一定规模了，慢慢体会到单元测试的作用。用Nunit进行单元测试能...