This was a pretty straightforward talk on the stuff you might expect. Barrett set up sister test projects for testable projects in a Visual Studio solution and used MOQ for mocking, and so on. He used Unity for dependency injection instead of StructureMap, but it too offers the trick of autohydrating interfaces at the constructor signature of MVC controllers and this ultramodern tricky was referred to as the "Unit of Work" pattern. So what did I learn that was new for me?
- If you make a change and that breaks something which previously worked that is a regression.
- The Boy Scout mantra of "Leave it as you found it." (honestly, I think it's really: "Leave the campground cleaner than you found it.") applies to writing tests. They should be nullipotent and running them zero times or one hundred times should cause the same number of effects (zero) on the code base and beyond. If you are putting things to a database in an integration test you should also be cleaning it back away as part of your teardown process, etc. You should not be wrecking things with your tests.
- If you are making a change in a huge app with no unit tests, just worry about getting your change under test. You don't have to refactor the whole app into something testable. Just do the right thing for what you introduce.
- Simian is a tool that finds duplicate code in your code base so that you may consolidate it. One great way to get your code coverage statistic up is to reduce the duplicate code. Slapping the [ExcludeFromCodeCoverage] attribute on things is even better! (I'm kidding.) NCover is the code coverage tool Barrett uses. dotCover is an open source version of the third version of NCover per Mr. Simms even though it's also clearly a JetBrains not-free product. Maybe I'm missing something. JetBrains ReSharper also has some code coverage capabilities baked into it with all the other magic.
- Don’t write tests around T4 (Text Template Transformation Toolkit) template stuff unless it's your own T4 stuff.
- BaseAspNetAngularUnity is an open source GitHub project that Barrett made for getting starting doing things his way. It has a better nude MVC app (his opinion) than the out-of-the-box one that comes out of Visual Studio by default. His thing has MOQ in test projects and AngularJS and Unity already cozy together.
- It's almost impossible to get code coverage up to 100%. Chill out.
- At the end of the talk Barrett asked the audience what qualities make for "good code" and a list which started with functional grew into: functional, readable, fast, maintainable, extensible, and testable, but unfortunately it started out as just functional alone and he heavily cautioned against using that alone as the gold standard. A 1973 Ford Pinto which takes you from A to B is not a quality car even though it's functional.
No comments:
Post a Comment