On top of that, while the class below does not much today - who knows what it will do next week. Before I modify something, I want to feel confident that I have tests backing any changes I make - whether it's generated or not, you should have tests for it (as William said, these should also be generated).
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Bartholomew Sent: Saturday, September 08, 2007 6:01 PM To: [email protected] Subject: RE: [OzTFS] Actual code coverage results and proxy files Troy, There are actually some very good reasons to write unit tests for this class, but you're right, a developer shouldn't waste their time writing these tests, they should be generated... Here are the reasons I think this class should be tested: 1. Having a test that creates the class and asserts that it's not null will pick up a potential breaking change if a developer adds a constructor forgetting that this removes the compiler's implicit default constructor. 2. It is helpful to have a test that asserts the default values that are expected when a class is constructed, this is especially useful if there are multiple constructors though. 3. Unit tests for property getters and setters picks up the oh so common situation where a property definition has been copied and the developer forgets to change either the getter or the setter. A lot of properties are more complicated than a pure get/set anyway, they often have some form of validation. It is easy to forget that unit tests can be of more benefit than just testing, I think they are a powerful (although not perfect) way of picking up breaking changes. Regards, William From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Troy Gould Sent: Friday, 7 September 2007 4:59 AM To: [email protected] Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [OzTFS] Actual code coverage results and proxy files This is no holy grail of acceptable code coverage. Add all the indirection, dependency injection and mocking, and you aren't going to get to 100%. Even more, you probably shouldn't get to 100% Would you unit test the following class? public class MyClass { private string someVariable; public string SomeVariable { get { return someVariable; } set { someVariable = value; } } } I've seen people write tests like the following [TestMethod] public void ShouldCreateNonNullMyClass() { MyClass instance = new MyClass(); Assert.IsNotNull(instance); } The same goes with testing the getter/setter. That is just plain silly to test, and a waste of time. Same goes with generated proxy code. At some point you start unit testing the CLR or the proxy generator tool. You should be more worried about having good coverage in places that you are refactor or fixing a bug. Also, set a baseline. Ask questions when your coverage goes lower from the previous build to the current. You should look at places that have low code coverage and ask yourself if they are candidates for breaking up into smaller classes, using interfaces and dependency injection along with mocking in order to drive up the test coverage. If your proxy code constitutes 25% of your code base, then setting your goal at 90% probably isn't realistic. You shouldn't worry about getting 100% coverage of your proxies unless you feel that your deployments aren't going well, and want to run functional/integration tests after your (automated) deployment. Regards, Troy Gould Sr. Consultant ThoughtWorks Pieter de Bruin <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/05/2007 03:40 AM Please respond to [email protected] To <[email protected]> cc Subject [OzTFS] Actual code coverage results and proxy files Hey all, We are trying to get best possible results out of code coverage. It looks like this is getting a long nicely, but we're struggling with generated code and web service proxies in particular. I've read that code coverage metrics aren't the holy grail [1] and that you can put generated code in separate projects [2]. Is that also your opinion? Do you have a better way of working normally with proxy classes and still get acceptable code coverage results? Thanks, Pieter [1] http://blogs.msdn.com/bharry/archive/2007/05/07/managing-quality-part-7-code-coverage.aspx [2] http://geekswithblogs.net/sbellware/archive/2005/05/01/38845.aspx OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com - List managed by www.readify.net
