I'll be attending the AltNetConf . Convenient for me that it's in Austin, TX. It's an open space conference, and I consider it the founding conference of a conversation that is "Alt.Net". I'll be proposing the topic: What are the Alt.Net principles? . The definition of Alt.Net...

I have learned an important lesson from my combined experiences at all the places I've worked. That is: raw requirements cause waste. A term I've used (and have heard others use) is that requirements are either "baked" or "not baked". For a development team to plan an iteration...

If you remember the article in October that was on MSDN on Test-Driven Development, you remember the hub-bub that it caused because of the inaccuracies, and how it soon was pulled from the web. Microsoft has published new Guidelines for Test-Driven Development . See the article to see why I think they...

In this post, I'll talk about and demonstrate integration testing. If you are just starting out with integration testing, you want to test small before you test big. Full-system tests are good, but if they fail, they don't give much of a hint as to where the failure is. Smaller integration tests will...

I use NUnit for my automated tests. Because of that, all my tests are unit tests, right? WRONG! The name of the testing framework has no bearing on the type of test you have. NUnit is a framework for running automated tests. You _can_ write unit tests with it, but you can also write integration tests...

Reality In reality, developers don’t like to do much testing. Developers aren’t testers. We typically will write code while making certain assumptions about variables and, objectively knowing the expected behavior of the syntax, we might run it once and call it done. Typically, bugs hide where the code...

I've posted on a retrospective of my team's current release , and I've run a few code analysis numbers to get a baseline trend. I normally don't do code analysis since working code is our real goal, but here it is: I analyzed our latest component, which is a part of a larger software product. This component...

Here is the main reasoning for this: TDD states that a unit test is written before a unit of code. Each unit of code will have a unit test. When a unit of code needs to be refactored (changed in structure without affecting behavior), the unit test will preserve the behavior of the code. The unit can...

If a class is well-designed, it will be easy to unit test. Good design speeds up unit testing, and TDD reveals bad design. In this way, TDD speeds up unit testing . For a very simple example, consider a controller class that takes a domain object and saves it to the database using a data access class...

Before reading this post, I recommend reading a previous post of mine along with the comments and trackbacks to related posts. First, you may wonder why I'm contending that TDD speeds up unit testing if TDD itself stresses unit testing so much. One can unit test without employing TDD. I can write some...