Good Resource to Learn Bdd, Tdd (Ruby , C#, JavaScript)

Why should I practice Test Driven Development and how should I start?

There are a lot of benefits:

You get immediate feedback on if your code is working, so you can find bugs faster
By seeing the test go from red to green, you know that you have both a working regression test, and working code
You gain confidence to refactor existing code, which means you can clean up code without worrying what it might break
At the end you have a suite of regression tests that can be run during automated builds to give you greater confidence that your codebase is solid

The best way to start is to just start. There is a great book by Kent Beck all about Test Driven Development. Just start with new code, don't worry about old code... whenever you feel you need to refactor some code, write a test for the existing functionality, then refactor it and make sure the tests stay green. Also, read this great article.

Beginning TDD - Challenges? Solutions? Recommendations?

First, it is alright and normal to feel frustrated when you first start trying to use TDD in your coding style. Just don't get discouraged and quit, you will need to give it some time. It is a major paradigm shift in how we think about solving a problem in code. I like to think of it like when we switched from procedural to object oriented programming.

Secondly, I feel that test driven development is first and foremost a design activity that is used to flesh out the design of a component by creating a test that first describes the API it is going to expose and how you are going to consume it's functionality. The test will help shape and mold the System Under Test until you have been able to encapsulate enough functionality to satisfy whatever tasks you happen to be working on.

Taking the above paragraph in mind, let's look at your questions:

If I am using a collection in my system under test, then I will setup an expectation to make sure that the code was called to insert the item and then assert the count of the collection. I don't necessarily test the Add method on my internal list. I just make sure it was called when the method that adds the item is called. I do this by adding a mocking framework into the mix, with my testing framework.
Testing strings as output can be tedious. You cannot account for every outcome. You can only test what you expect based on the functionality of the system under test. You should always break your tests down to the smallest element that it is testing. Which means you will have a lot of tests, but tests that are small and fast and only test what they should, nothing else.
There are a lot of open source testing frameworks to choose from. I am not going to argue which is best. Just find one you like and start using it.
- MbUnit
- nUnit
- xUnit
All you can do is setup your tests to account for what you want to happen. If a scenario comes up that introduces a bug in your functionality, at least you have a test around the functionality to add that scenario into the test and then change your functionality until the test passes. One way to find where we may have missed a test is to use code coverage.

I introduced you to the mocking term in the answer for question one. When you introduce mocking into your arsenal for TDD, it dramatically makes testing easier to abstract away the parts that are not part of the system under test. Here are some resources on the mocking frameworks out there are:

Moq: Open Source
RhinoMocks: Open Source
TypeMock: Commercial Product
NSubstitute: Open Source

One way to help in using TDD, besides reading about the process, is to watch people do it. I recommend in watching the screen casts by JP Boodhoo on DNRTV. Check these out:

Jean Paul Boodhoo on Test Driven Development Part 1
Jean Paul Boodhoo on Test Driven Development Part 2
Jean Paul Boodhoo on Demystifying Design Patterns Part 1
Jean Paul Boodhoo on Demystifying Design Patterns Part 2
Jean Paul Boodhoo on Demystifying Design Patterns Part 3
Jean Paul Boodhoo on Demystifying Design Patterns Part 4
Jean Paul Boodhoo on Demystifying Design Patterns Part 5

OK, these will help you see how the terms I introduced are used. It will also introduce another tool called Resharper and how it can facilitate the TDD process. I couldn't recommend this tool enough when doing TDD. Seems like you are learning the process and you are just finding some of the problems that have already been solved with using other tools.

I think I would be doing an injustice to the community, if I didn't update this by adding Kent Beck's new series on Test Driven Development on Pragmatic Programmer.

Test driven JavaScript, Jasmine, and production code

Jasmine is a framework for testing JavaScript code. Just like testing Ruby on Rails code, the tests don't become part of the production code. They are in the same repo and are run but they aren't minified into project.js or whatever your build process is. As part of your test run process, you can do headless tests using PhantomJS (headless webkit) and have it run on your CI server and so forth just like any other test.

I have worked on a bunch of projects this way. There has been a trend of seeing JavaScript has an enhancement layer that doesn't really need to be tested but today JavaScript is so much more. It is critical to test it if your application needs to work.

What's the best BDD framework for working with ASP.NET MVC 2 + C# 4?

I see this question already has an answer, and I have not tried NBehave. But, we are using MSpec (Machine.Specifications) for this fairly large Enterprise project and it is working quite well for us here. Very well worth mentioning.

Rob Conery did an EXCELLENT video on Learning BDD, where he uses MSpec, line by line:
(link removed, no longer available, but search for it)

More about MSpec from Rob Conery, and why he uses it.

http://wekeroad.com/2009/09/21/make-bdd-your-bff-2/ You might also want to check out his other posts tagged BDD as well.

Pros:

Allows for quickly "stubbing" of your entire Story, Scenerios, Contexts, and Specifications - without any actual code. Let's you focus on the overall "Behaviors", which is the purpose of BDD!, without worry about code and making it compile.
Produces an EXCELLENT HTML report, with "<- NOT IMPLEMENTED" next to stubbed specifications. I often hand this report to: The Client (CEO and CTO), The Testers, New Resources I bring onto the project, and anyone else that wants to know how the software works - without me having to show a line of code!
TestDriven.NET runners are included with MSpec using the new tdnet linking (no setup!).
The [Behaviors] attribute, along with its Behaves_like delegate type, makes copying existing specifications from one scenerio over to other another scenerio a snap.

Cons:

Little to no documentation, even though not much is needed (watch the videos above). The author recently blogged for help on documenting.
Still new, and just a side-project from the author (not his main gig). But, it is very active as of this post.

Hope that helps.

Eat, Sleep and Breathe Unit Testing/TDD/BDD

A good place to start is reading blogs. Then buy the books of the people who are blogging. Some I would highly recommend:

"Uncle Bob" Martin and the guys at Object Mentor:
http://blog.objectmentor.com/

P.S. get Bobs book Clean Code:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

My friend Tim Ottinger (former Object Mentor dude)
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/

The Jetbrains guys:
http://www.jbrains.ca/permalink/285

I felt the need to expand on this, as everyone else seems to just want to give you their opinion of TDD and not help you on your quest to become a Jedi-Ninja. The Michael Jordan of TDD is Kent Beck. He really did write the book on it:

http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

he also blogs at:

http://www.threeriversinstitute.org/blog/?p=29

other "famous" supporters of TDD include:

Tim Bray
Martin Fowler
Ward Cunningham

All are great people to follow. You should also consider attending some conferences like Agile 2010, or Software Craftsmanship (this year they were held at the same time in Chicago)

BDD with Cucumber and rspec - when is this redundant?

Good question, one I've grappled with recently while working on a Rails app, also using Cucumber/RSpec. I try to test as much as possible at every level, however, I've also found that as the codebase grows, I sometimes feel I'm repeating myself needlessly.

Using "Outside-in" testing, my process usually goes something like: Cucumber Scenario -> Controller Spec -> Model Spec. More and more I find myself skipping over the controller specs as the cucumber scenarios cover much of their functionality. I usually go back and add the controller specs, but it can feel like a bit of a chore.

One step I take regularly is to run rcov on my cucumber features with rake cucumber:rcov and look for notable gaps in coverage. These are areas of the code I make sure to focus on so they have decent coverage, be it unit or integration tests.

I believe models/libs should be unit tested extensively, right off the bat, as it is the core business logic. It needs to work in isolation, outside of the normal web request/response process. For example, if I'm interacting with my app through the Rails console, I'm working directly with the business logic and I want the reassurance that methods I call on my models/classes are well tested.

At the end of the day, every app is different and I think it's down to the developer(s) to determine how much test coverage should be devoted to different parts of the codebase and find the right balance so that your test suite doesn't bog you down as your app grows.

Here's an interesting article I dug up from my bookmarks that is worth reading:
http://webmozarts.com/2010/03/15/why-not-to-want-100-code-coverage/

What are some good approaches for stubbing dependancies in TDD?

To address your specific concern take a look at https://github.com/xaviershay/rspec-fire to guard against stubbing non-existent methods.

I think the broader problem here is that you are not listening to the feedback trying to write this test is giving you. A test which is difficult to write is a good sign of either a poorly designed test subject or that the testing technique you are using is not a good fit.

What would this class look like if it did followed the law of Demeter (hard with ActiveModel relations)?
What would your test look like if you supplied a test double object instead of attempting to mock every method?
What would your test look like as an integration test?

I think the best resource for writing better tests is to look at the design of the code being tested instead. http://www.poodr.com/ might be a good resource. http://www.martinfowler.com/bliki/TestDouble.html is a good overview of test doubles you might not be considering while http://blakesmith.me/2012/02/29/test-stubbing-as-an-antipattern.html makes an argument for why mocks might be the wrong tool entirely.
Specific to rspec http://betterspecs.org gives some hits what a good spec might look like. If those are hard to write that's a good hint that there's a broader problem.