Behavior Driven Development (BDD) is being increasingly seen as an alternative way to approach Test Driven Development. SpecFlow and NSpec are popular frameworks for BDD in .NET. They help create test specifications that are easy to read even for non-programmers and allow the design of the software to be driven by it’s purpose.
James Whittaker, a former Microsoft architect, author of several books in the “How to Break Software” series, and currently Director of Test Engineering at Google, has written a series of posts on how Google does testing. Google blends development with testing, having relatively few testers, and each product goes through successive channels before is ready for prime time.
A new form of an old question has been asked in the Behavior Driven Development community: is BDD merely Acceptance Test Driven Development done well? While the community calls out the differences, Dan North makes a request to avoid focusing on them, calling TDD "amazing".
Daniel Markham, an agile coach, is asking the question "why there are some "seriously pissed off people about Agile out there? Isn't agile supposed to be warmth, apple pie, motherhood, goodness and all of that? Why so much anger?"
TestDriven.NET, a TDD add-in for Visual Studio, has reached version 3.0. Some of the new features are: support for MSTest, .NET Reflector 6 Pro, VS 2010, Silverlight 4, NUnit 2.5.3, using the project’s .NET framework and others.
Real Options, a decision-making process based on Financial Option mathematics, was mentioned by Kent Beck in his 1999 "white book," Extreme Progamming Explained. More recently, Agilists have been exploring how Real Options intersects with Agile. Now Chris Matts and Olav Maassen specifically address the Lean Software community, proposing that application of Real Options improves Lean Development.
Alan Baljeu was trying to use TDD with his large, legacy C++ code base. He found that the principle of the simplest thing that could possibly work was causing him trouble with the amount of rework.
JetBrains has taken it on themselves to create one of the premier Ruby IDEs on the market. It has been just over 6 months since version 1.0 was released and today, RubyMine 2.0.
Following up a pot-stirring blog where he asserted that "anyone who continues to think that TDD slows you down is living in the stone age", Bob Martin takes a stab at providing some deeper insight into the real applicability, role, and benefit of TDD.
It is often the case, a new piece of software is developed by someone who needed to fill a void left by an existing product. Software evolves from tools we use which don't exactly meet our needs, this is the case with a new Behavior Driven Development (BDD) tool called Coulda, developed by Evan Light.
One thing well known by most programmers is that the best (only?) way to learn programming technique is by example; specifically, watching someone else doing it. Antony Marcano & Andy Palmer's 'PairWithUs' gives people a great place to do just that.
There are plenty of choices for creating mock objects in Java but Flex has seen little development in this area, until recently. The popular and maturing Mockito framework now has a Flex counterpart, which aims to bring mocking to Flex.
Many people playfully credit the 3x5 index card as the "agilist's badge". In many ways though this is not an inaccurate or inappropriate; going through a stack of index cards is a often real hallmark of many agile activities. But what about using index cards to learn and remember agile? With their 'Agile In a Flash' project, Tim Ottinger and Jeff Langr want to help people do just that.
Kent Beck suggests that on very short term projects, when you're trying to figure out if there is a viable concept, you might do less (even no) automated testing to help get off the ground quickly. This goes against all of the conventional wisdom surrounding TDD.
"Test-driven Development" and "Pair Programming" are two of the most widely known of agile practices, yet are still largely not being practiced by many agile teams. Often, people will cite being "too busy" to adopt such practices as TDD and pairing; in essence, implying that striving for high code quality will reduce productivity. Mike Hill explains how this logic is seriously flawed.