Things I learned at Agile Up To Here*

After 25 years, it’s time to lose the Windows computer and get a Mac.

Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.

There are lots of programmers who understand that relational databases are not the only approach to solving problems.

It is time to build software.

Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.

When even the leanest developer in the room sees really high quality BDUF for the first time, they get all woo-woo and want some for themselves.

Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.

Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).

Even this jaded old fart can still get excited about changing the world.

There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.

People want a leader with a vision.

Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.

The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD code is properly regarded like a ticking time bomb.

For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.

Story-mapping is a major component of the bridge between interaction design and agile development.

Story-tracking software isn’t quite there yet.

Data-miners think differently. I don’t think like a data-miner.

The Union Pacific Railroad, headquartered in Omaha, is not as “Dilbert-y” as it might seem.

There’s an app for that.

Pointy-haired managers are soooo counter-productive.

While I cling to my tree-based books and papers, bit-based books and papers are actually more capable in many ways. Is my nostalgia based on familiarity rather than quality? Did you just feel the Earth move, too?

Social programming.

While everyone expounds breathlessly about browser-based apps, they still spend the lion’s share of their time using native, client-side apps.

Software patterns are a powerful tool.

Sometimes there’s a necessary part of a program that is just ugly. You can refactor or reconceptualize it, but instead of shrinking it, you’re just moving the ugly part around. I call this the “Irreducible Nugget of Ugliness”, or INU.

I love inventing new TLAs.

While easier than it used to be, it’s still hard for an old software guy like me to keep his hands off.

Some people are perfectly content to not know about the personas and they still get good work done right.

There’s nothing new under the sun.

At a granular level in software development, what used to be easy is hard, and what used to be hard is easy. At a broader level, creating software still remains one of the most difficult things you can attempt.

The power of web development and modern tools is so great that it tempts even me to de-emphasize the user’s goals.

I worry a lot about applying an indelible Sharpie to a precious whiteboard.

Face time is vital when you are creating. If you are creating a product, you need face time with the product team; if you are creating a company, you need face time with everyone in the company.

Flickr is a steaming pile of software.

The only way to really get to know individual people is by devoting attention and time to them. The only way to really get to know your craft is by devoting attention and time to it. This is most definitely not a coincidence.

There are still a few bugs in the system.

The road to mastery is simple: just imagine the problem-set as being far bigger than everybody else does, and then give it attention appropriate to its size.

When you’re in the groove, there’s no 9 to 5.

When you finish something, ring a bell.

Dale Emery (@dhemery) said “I can give you a silver bullet, but be aware that you might be the werewolf.”

Candy remains a powerful motivational tool in the software world. Or maybe it’s just that the brain requires lots of cheap energy.

When you own something, you lose a lot of perspective about it.

Product ownership is far too complex and important to be left to amateurs, even if they actually own the product.

It’s okay to sit down during a Stand-up.

When you are really good at doing some job, you are usually unaware of the important nuances that make you so good.

Establish one really big goal, then establish lots of little, intermediate tasks that will get you to your goal. Then celebrate each task as you achieve it.

Model-View-Controller.

At a certain point the barriers to entry fall so low that no excuses withstand scrutiny.

*Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.

She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here.

Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much.

If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.

Tags: agile, agilistry, design, learning, pairing, programming, software, tdd, testing

This entry was posted on Sunday, May 16th, 2010 at 12:40 PM and is filed under Interesting Stuff, Responsible Craftsmanship, software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

View the original article here

Rediscovered posts about TDD

I rediscovered some old blog posts about my view of TDD yesterday.

It’s in Swedish and they discuss TDD from three different points of view: safety net, documentative effect and design implications.

I also re-read an article about using TDD in games development and that article mentions an aspect of TDD which I didn’t discuss in my TDD posts: the quick-feedback effect.

The quick-feedback-effect might be the least obvious of the four; but nonetheless I think it might be the most important one from a psychological/human viewpoint.

I want to discuss what I mean with that more deeply in some other post, but in short it’s the idea that getting feedback from your software quickly is nice. TDD reimburses your efforts faster than manual testing, and reimbursement is fundamental to keep programming fun.

Tags: tdd, fun, feedback

View the original article here

#285 Spork

Spork improves the loading time of your test suite by starting up your Rails application once in the background. Use it with Guard for the ultimate combo in fast feedback while doing TDD.

View the original article here

.NET Web Developer

CompanyOneWire, Inc.LocationNew York, United StatesSalarymedical, dental, paid vacation, stock options, great work environment

OneWire is a transformational career management and hiring tool that uses patent pending matching technology that enables companies to confidentially and precisely connect with relevant candidates at every level.

For job seekers, OneWire is a confidential place to manage a career for life and be matched to relevant job opportunities. For employers, OneWire is a recruitment solution that allows them to source candidates at every level and control the entire recruitment process, from candidate discovery to on-boarding. For colleges and universities, OneWire is a campus recruiting tool that enables the Career Services Office to manage and administer the entire process, on- or off-campus.

OneWire has been named one of America’s Most Promising Startups by Business Week (January 2010) and has been featured in NYT, CNBC, MSN, Forbes, NPR, and other major publications.

We have several spots open for top notch .NET / C# / MVC developers to join our team as we continue to change the face of online recruiting. The base technology set is Microsoft-centric (.NET / C# / SQL Server / MVC) along with heavy JQuery, a bit of knockout.js, and some MongoDB thrown in for good measure.

You'll be involved in all stages of the development process, working with a great team at an early stage company.

https://www.onewire.com/p_7421-ASP-NET-MVC-Developer.aspx

View the original article here

Automated hardware testing of Surface with Patty the robot

There's only one thing we love more than software patent arguments, the prospect of Windows 8 and C++ here at developerFusion: robots. And have we got a good one for you this week: robots and Microsoft Surface combined.

Microsoft's robot called "Patty" sits inside the Surface testing lab at Microsoft HQ in Redmond. Its purpose is very simple - how do you test one of the brand new Surface 2.0 devices to make sure it can cope with all of the gestures, touches and more that the device will have to handle, while stress testing it over its lifetime?

Patty solves this problem by encorporating 80 touch "fingers", actuated by pressurised air. These can be rotated in four sections to create multi-touch gestures on the surface. It can even simulate "entire classes" of people, for example students, using the device at the same time. Additionally the robot is capable of moving across the plane of the Surface device to actuate anywhere on the surface.

The testing team also had to put together the software to control the various components of the robot, and to provide a nice interface to make for substantially easier test development.

Find out more about the robot in a video on the Surface blog.

View the original article here

BackTrack 4: Assuring Security by Penetration Testing

Written as an interactive tutorial, this book covers the core of BackTrack with real-world examples and step-by-step instructions to provide professional guidelines and recommendations to you. The book is designed in a simple and intuitive manner, which allows you to explore the whole BackTrack testing process or study parts of it individually. If you are an IT security professional or network administrator who has a basic knowledge of Unix/Linux operating systems including awareness of information security factors, and you want to use BackTrack for penetration testing, then this book is for you.

View the original article here

Design for testing

Design for testing - TDD tutorial - developer Fusion Developer Fusion - The global developer community for .NET and Java programmers .NET Java Open Source Mobile Database Architecture Agile Test Driven Development CQRS nTier Patterns SOA RIA & Web Toolbox Test Driven Development News Tutorials Code Training User Groups Books Podcasts Forum Jobs Home Architecture Test Driven Development Tutorials Design for testing 17 May 2011 | by Kevin Jones | Filed in Comments PDF Test Driven Development LINQ ASP This article was originally published in VSJ, which is now part of Developer Fusion.

Developers generally agree that unit testing is a good idea, however not all of us know how to go about authoring code that is testable. The solution proposed in this article involves deliberately inserting a mechanism for testing at the point that you write the code. For example, if I need to access a database I typically create some kind of data access layer. That layer provides a facade over the database, I create instances of objects from that layer to perform the database access. If I want to test the data access code I need to be able to stub in the database. If I need to test the code that uses the data access code I need to be able to stub in the data access layer. This article will talk about the various approaches we have to writing code that is testable looking at factories, dependency inject and “inversion of control”.

Layer code

The first rule of design for test is really very straightforward. Write your code in layers. Taking the above example; instead of sprinkling your data access code throughout your business logic, separate the data access code into layers. You often see data access code written as two layers, a low level data access layer and a higher level ‘entity’ layer. The lower level layer provides an API that actually talks to the database, maybe through stored procedures, or through parameterized statements and maybe today through a LINQ layer such as LINQ to SQL. The entity layer exists at a higher level and provides methods such as GetAllCustomers, UpdateCustomer or GetInvoicesFor Customer. This layer calls the lower level methods in the data access layer. Depending on the complexity of the application you may not need to separate the code into this many layers, but layering is always a good idea.

Breaking the code into the layers suggested above you will make testing easier as each layer can be tested separately. As the entity layer is independent of the database then no database is needed to test it, all that need be test (and all that should be tested) is the logic within the layer. Another aspect of layering is that no domain specific code should leak into the business code. For example if you are coding a web application the business logic should be in classes that are entirely separate from the UI code. No UI code should be used in the business logic layer. This is easy to achieve in practice, however it is all too easy to see code like this:

ActionView GetUsers(int id) { User.GetUsers(HttpContext.Current); ...}

In this case there is a GetUsers business method, but this is being passed an HttpContext which is an ASP.NETet type. This means that the User type depends on the ASP.NETet assemblies and also that to test the User type you will need to create a dummy HttpContext, which is a non-trivial task that you shouldn’t need to do. Writing the method like this:

ActionView GetUsers(int id) { string startsWith = Request.Params ["startsWith"] as string User.GetUsers(startsWith); ...}

…means that the GetUser method takes a string. This is much better layering and makes the code much easier to test.

Use of ‘new’ considered evil!

One of the cardinal rules of software development is ‘code to abstractions and not to concrete types’, and it cannot be emphasised strongly enough how important this is. By coding to concrete types you are limiting yourself to specific implementations within your application. While at first glance this seems reasonable it means that you cannot substitute those types for doubles when you want to test the code. If the concrete types touch a database, the file system or maybe a web service then this makes testing much harder than it should be. By coding to abstract types and also abstracting away object creation you allow doubles to be substituted in much more easily.

For example, code like this:

public IEnumerable GetUsers() { UserDAO dao = new UserDAO(); return dao.GetUsers();}

…is inherently non- testable, or at least is very difficult to test. This is because the code is using a concrete type UserDAO. This DAO will call some other type which will access a database. This means that either the types used by the UserDAO must be dummied up or the database access must be faked, maybe by using a test database. Instead of this the code should be written against a UsersDAO abstraction, either an interface type or an abstract class. The code would then look like:

public IEnumerable GetUsers() {// IUserDAO idao = GetUserDAOSomehow(); return idao.GetUsers();}

Of course this leaves us with the problem of getting hold of a UsersDAO instance and the rest of this article will discuss those options.

Dependency injection

Dependency injection is a phrase that has come into use over the last few years. It’s an important sounding phrase for a straightforward concept. The basic idea is simple, rather than a type or method, create the objects it relies on, i.e. those objects that are passed into the object or method. Why dependency injection? Well objects depend on other objects, and thus dependent objects are passed into, or injected into the depending objects.

Dependencies can be injected in three ways: parameter injection, setter injection or constructor injection. To examine these uses we will write examples around a ManageAuthors class. This class looks like this:

public class ManageAuthors{ public Author GetAuthor(int id) { AuthorDAO authorDao = new AuthorDAO(); return authorDao.GetAuthorWithId(id); }}

This uses an AuthorDAO class that looks like this:

public class AuthorDAO{ public Author GetAuthorWithId( int au_id) { return new Author() {FirstName = "Kevin", Surname = "Jones" }; }}

As mentioned above the code is difficult to test. The DAO is hard (impossible) to replace. To make this code testable we need to code to an abstraction rather than a concrete type (the AuthorDAO). There are several steps that need to be completed to do this.

The first thing to do is to create an abstract type that the ManageAuthors class can use instead of the AuthorDAO. The AuthorDAO needs to derive from this abstraction. We then end up with classes something like this:

public interface IAuthorDAO{ Author GetAuthorWithId(int au_id);}public class AuthorDAO : IAuthorDAO{ public Author GetAuthorWithId( int au_id) { return new Author() { FirstName = "Kevin", Surname = "Jones" }; }}

Now that we have the interface (the abstraction) in place we can code against it. The simplest way to do this is to use parameter injection. This involves changing the signature of the method to accept a parameter of the correct type:

public Author GetAuthor( IAuthorDAO authorDao, int id){ return authorDao.GetAuthorWithId(id);}

Notice that now the IAuthorDAO is being passed to the method. This makes the method easily testable:

[Test]public void TestValidAuthor(){ ManageAuthors sut = new ManageAuthors(); IAuthorDAO idao = new MockAuthorDAO(); Author a = sut.GetAuthor(idao, 1);}

Where the MockAuthorDAO class looks like this:

public class MockAuthorDAO : IAuthorDAO{ #region IAuthorDAO Members public Author GetAuthorWithId( int au_id) { return new Author() { FirstName = "Foo", Surname = "Bar" }; } #endregion}

Notice that the method now doesn’t create the object it depends on, instead the object is injected via the parameter passed to the method.

One problem with this mechanism is that existing code has to change, in fact it’s worse than that as existing method signatures have to change, this could mean a lot of code changes in a large code base.

To mitigate this we could use ‘setter injection’. Now, rather than inject the dependencies via a parameter the class is re-written to have a property that is set by external code. This property is of the abstract type, IAuthorDAO in the above code. The ManageAuthors class now changes to look like this:

public class ManageAuthors{ public IAuthorDAO AuthorDAO { get; set; } public Author GetAuthor(int id) { return AuthorDAO.GetAuthorWithId(id); }}

This is better as less code has to change. However there is still a danger here. While the ManageAuthors class doesn’t need to change as much, all the code calling it does need to change. The danger now is that all the places where the calling code uses the GetAuthor method have to remember to inject the IAuthorDAO, and this may be missed.

The third option is to use constructor injection. In this case the ManageAuthors class would be changed to have a constructor that takes an IAuthorDAO as a parameter. The code would then look like:

public class ManageAuthors{//readonly IAuthorDAO authorDAO; public IAuthorDAO authorDAO { get; set; } public ManageAuthors( IAuthorDAO authorDAO) { if (authorDAO == null) throw new ArgumentNullException( "authorDAO"); this.authorDAO = authorDAO; }}

Calling this code then involves passing an IAuthorDAO to the ManageAuthors constructor:

[Test]public void TestValidAuthorWithConstructor(){ ManageAuthors sut = new ManageAuthors( new MockAuthorDAO()); Author a = sut.GetAuthor(1); Assert.AreEqual("Foo", a.FirstName); Assert.AreEqual("Bar", a.Surname);}

This has the benefit that it signals to all the calling code exactly how the class should be used, i.e. an IAuthorDAO must be passed to the constructor. Any code compiled against the ManageAuthors class would fail to compile; this is a strong signal that the code is wrong! However, if the ManageAuthors code is used by a lot of other assemblies then re-coding the classes in those assemblies may be a long and tedious process.

Another cardinal rule of software development is ‘don’t change working code’, in this case a lot of working code would have to be touched. To mitigate this, the ManageAuthors class could be changed to have a default constructor that called the new constructor. The class would look something like:

public class ManageAuthors{ readonly IAuthorDAO authorDAO; public ManageAuthors():this( new AuthorDAO()){} public ManageAuthors( IAuthorDAO authorDAO) { if (authorDAO == null) throw new ArgumentNullException( "authorDAO"); this.authorDAO = authorDAO; }}

Care needs to be taken with this approach to ensure that the correct class is instantiated in the default constructor and that new code does not use the default constructor. A better approach may be to have the default constructor create a ‘faulting’ IAuthorDAO, one that logs the fact that it shouldn’t be called and then throws an exception. This means that as the ManageAuthors class is distributed more widely, code using it can be updated more easily.

Of the three approaches to dependency injection, parameter, setter and constructor, constructor is the most widely used. It is generally easier to retro-fit to existing classes and also makes it relatively easy to get existing code to work with the changed ManageAuthors class if the default constructor is kept in place.

Factories

Suppose you find for whatever reason that you cannot or simply do not want to use dependency injection, how do you go about creating objects without the use of the new keyword? One option is to use a factory. The Gang of Four patterns book lists two factory patterns, the factory method and the abstract factory. An abstract factory is simply a collection of factory methods, so understanding factory method leads you to an understanding of abstract factory.

In the factory method pattern the idea is to define a type that is able to create the type you want to use. For the AuthorDAO type above we’d create an AuthorDAOFactory. Factories can also be substituted. So, like any other types, when defining a factory it makes senses to define a base abstract factory and then define concrete instances of that abstraction that our code actually uses. The code for using the factory will look like this:

public Author GetAuthorWithFactory( int id){ AuthorsDAOFactory factory = LoadFactory(); AuthorsDao = factory.GetAuthorsDAO(); return AuthorsDao.GetAuthor(id);}

Here we load the factory (we will see how to do this in a moment), then uses the factory to create the AuthorsDAO object which we can finally call.

The factory code looks like this, first the abstract class:

public abstract class AuthorsDAOFactory{ public abstract AuthorsDAO GetAuthorsDAO();}

…then the concrete implementation:

public class SimpleAuthorsDAOFactory : AuthorsDAOFactory{ public override AuthorsDAO GetAuthorsDAO() { return new SimpleAuthorsDAO(); }}

The factory method pattern gets its name from the fact that there is one method in the class whose job it is to create the object we care about. Notice that this code uses ‘new’. This makes sense – ‘new’ has to be used somewhere, our job is to abstract away where ‘new’ is used.

Notice that the ManageAuthors class uses the abstract AuthorsDAOFactory type which returns an abstract AuthorsDAO type. This means that all our code relies on abstractions, making testing much easier. A test for this method would look like this:

[Test]public void TestWithFactory(){ ManageAuthors manageAuthors = new ManageAuthors(); Author author = manageAuthors. GetAuthorWithFactory(1); Assert.AreEqual("Alice", author.Name);}

Notice that there is no mention of a factory here. The factory is set up purely using configuration. The main application’s configuration file (with the real factory in) would look like:

…while the test configuration file looks like this:

So changing the configuration changes the factory being loaded. This helps solve the mystery of how the ManageAuthors class loads the factory. The LoadFactory method gets the factory type name and assembly from the config file, then uses reflection to load the assembly and create an instance of the factory:

private static AuthorsDAOFactory LoadFactory(){ string typeAsString = ConfigurationManager. AppSettings["factory"]; Type type = Type.GetType(typeAsString); AuthorsDAOFactory factory = (AuthorsDAOFactory)Activator. CreateInstance(type); return factory;}

The configuration file stores the factory as a fully qualified type name which can then be loaded using Type.GetType. This means that not only is testing easier but anytime we want to change the factory it is simply a configuration update.

However, this is still an issue. For example, if you want to test multiple factories then the configuration needs to be changed every time, meaning multiple app.config files in multiple test projects. Sometimes it would be nice to have a configuration option that can be overridden in code. This is where containers and inversion of control come into play.

Inversion of control

A container is an object where an application can store references to other objects and retrieve them later. The references can be stored by having the container read a configuration file and creating the objects, just as we saw for the factory. Or the application can create objects in code and store those references in the container. This is known as inversion of control because the control of creating the dependent object is taken away from the code using that object.

There are various containers available. In these examples we’ll use the Unity container provided by Microsoft as part of the Enterprise Library. This container can be configured in the application’s configuration file:

The first part of the file sets up the Unity configuration section handler. The unity section then configures the container. The unity section defines two aliases, these are there so we can refer to the types through the alias within the configuration file, rather than having to use fully qualified type names everywhere. We then set up aliases for the AuthorsDAO abstract type and the SimpleAuthorsDAO concrete type. Finally in the containers section we create a mapping between these two types. This mapping basically says, ‘when code asks for something of type AuthorsDAO give them a SimpleAuthorsDAO object’.

The configuration for the container must be loaded and parsed. Once that is done an application can then load objects from the container. To do this, provide a simple wrapper class:

public class Container{ private static Container container;// load configuration data here private Container() { ... } readonly IUnityContainer unityContainer = new UnityContainer(); public static Container Instance { ... } public T Resolve() { return unityContainer.Resolve(); } public void RegisterType() where TTo : TFrom { unityContainer.RegisterType< TFrom, TTo>(); }}

Note that the Resolve method is generic. The container will look up the type passed through the generic parameter and return its mapped type. This is used something like this:

public Author GetAuthorWithIoC(int id){ AuthorsDao = Container.Instance. Resolve(); return AuthorsDao.GetAuthor(id);}

…i.e. ask for an AuthorsDAO object and (hopefully) get return a SimpleAuthorsDAO object. Again this lets us test quite easily. Like for the factory, we create an app.config file to configure the container. But we can now also programmatically inject objects into the container. So in the test code we can do this:

[Test]public void TestWithIoC(){ ManageAuthors manageAuthors = new ManageAuthors(); Container.Instance.RegisterType (); Author author = manageAuthors. GetAuthorWithIoC(1); Assert.AreEqual("Alice", author.Name);}

Notice that we are registering a new MockAuthorsDAO with the container before calling the method under test. This will override the instance already in the container and the method under test will resolve AuthorsDAO to MockAuthorsDAO.

This use of containers is very nice. It gives the flexibility of configuration alongside the ability to override that configuration in code which makes managing testing in particular very straightforward.

Types of Test Doubles

In the above code we have written a very simple MockAuthorsDAO class to use for testing. This gets us into the murky world of ‘Test Doubles’. On his ‘bliki’ (www.martinfowler.com/bliki/TestDouble.html) Martin Fowler categorises the various test doubles. He makes a distinction between Dummies, Fakes, Stubs, Spies and Mocks. According to his definitions the ‘mock’ above is probably a Stub. Mocks are more full featured and typically are coded with ‘expections’. Something along the lines of ‘If I call this method passing the value 1, return ‘foo’, if I pass the value 2, return ‘bar’ and so on. Mocks can be built by hand but it is often easier to use a framework designed specifically to create them.

There are several mocking frameworks available and more are becoming available all the time. The most popular is probably Rhino Mocks but there are others such as Moq or NMock.You are recommended to try them and choose the one you prefer.

Conclusion

To make your code more testable you should follow a couple of simple rules. Firstly, write in layers. This makes each layer more testable. Secondly, code to abstractions. If you code to an abstraction you move away from calling ‘new’. This means that you can then get references to objects in other ways. Do this either through dependency injection, factories or containers. Using any of these mechanisms means that these references become pluggable and therefore more testable.

You might also like... Comments About the author Kevin Jones

Kevin Jones has been involved in software development and design for more years than he cares to remember, and has been involved in training and consultancy since 1990. He is the co-author of Se... Interested in writing for us? Find out more.

TDD tutorials Testing In An Agile World: The Heart Of A Developer Web Testing with MbUnit and WatiN Part 2: Controlling Localhost and IIS Express Can developers test their own code? Test-driven development with NUnit TDD books Experiences of Test Automation: Case Studies of Software Test Automation

Software test automation has moved beyond a luxury to become a necessity. Applications and systems have grown ever larger and more complex, and manual testing simply cannot keep up. As technology changes, and more organizations move into agile develo...

TDD forum discussion Asp.Net practical books related by davidkroj (1 replies) robe de mariée_Que pouvez-vous porter pour un mariage d'automne semi-formelle ?_robe de mariée by robesmariee (0 replies) robe de mariée_Que pouvez-vous porter pour un mariage d'automne semi-formelle ?_robe de mariée by robesmariee (0 replies) how to manipulate the design based on IF condition by johngokul (0 replies) ASP Login page to convert to HTML5 by ss2013 (0 replies) TDD podcasts Hanselminutes: Understanding BDD and NSpec with Matt Florence and Amir Rajan Published 1 year ago, running time 0h34m

Scott sits down with NSpec authors Matt Florence and Amir Rajan to talk about Behavior Driven Development (BDD). Where does one start with BDD? Is BDD just TDD with a fancier name or can it really chance how you design software? The NSpec guys set Scott on the right path.

TDD jobs RoR Developer @ Wimdu Wimdu GmbH in Berlin, Germany
Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Web Development ASP.NET Quickstart Programming news Java programming ASP.NET tutorials C# programming Developer Jobs ASP.NET Jobs Java Jobs Developer Jobs Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

Join us Sign in Pakistan Username Password Cancel “The generation of random numbers is too important to be left to chance.” - Robert R. Coveyou Send feedback Blog About us Contact us Advertise © 1999-2013 Developer Fusion Ltd Managed hosting by Everycity

View the original article here