Naming Conventions:
- Naming primary key in both database and in code: WidgetId (not Id, not ID, not WidgetID)
- General naming guidelines: http://msdn.microsoft.com/en-us/library/vstudio/ms229042 and http://msdn.microsoft.com/en-us/library/vstudio/ff926074
- For private data members within a class, use private in _fooId;
Unit Testing:
- Folder structure of tests should mimic folder structure of code under test: Foo and Foo/Identity should have Foo.Tests, and Foo.Tests/Identity
- Naming of projects containing unit tests: Foo.Tests
- Note - I find myself also using Foo.Tests.Unit and Foo.Tests.Integration to keep these separate
- Note - I also find myself labeling Integration Tests - such as with this MS Test attribute: [TestCategory("Integration")] - so that I can identify Integration tests and selectively run just Unit tests should I choose
- Naming convention for unit test methods - I like Roy's approach (http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html), except I prefer logical name in first part: so rather than (Roy's) [MethodName_StateUnderTest_ExpectedBehavior], I use [Function_StateUnderTest_ExpectedBehavior] - for example, SubdomainExtraction_InvalidSubdomain_ExceptionThrown, SubdomainExtraction_CompoundSubdomain_ExceptionThrown, SubdomainExtraction_ValidSubdomain_Parsed, LogicalArea_Condition_ExpectedOutcome...