I was doing TDD using NUnit. I was naming my NUnit tests in a behavioral style (like given, when, then). However I am now using MSpec for all my unit tests. I'm still writing tests first, using mocks, etc... so, they're still unit tests. But, I don't see a need for NUnit.
I am nervous to throw away all the effort I put into learning NUnit. Should I abandon TDD/NUnit completely, taking into consideration that BDD is TDD done right?
Now that you have embraced BDD you are following an "Outside-In" development approach.
A nice succinct definition of this development technique can be found at programmers.stackexchange.com. I quote:
"Outside-In (London school, top-down or "mockist TDD" as Martin Fowler would call it): you know about the interactions and collaborators upfront (especially those at top levels) and start there (top level), mocking necessary dependencies. With every finished component, you move to the previously mocked collaborators and start with TDD again there, creating actual implementations (which, even though used, were not needed before thanks to abstractions). Note that outside-in approach goes well with YAGNI principle."
When using BDD, you develop in a top-down manner and mock dependencies to satisfy your test. Once your BDD test passes you then revert to using TDD to implement concrete versions of the dependencies you encountered during your BDD test (using an "Inside-Out" approach).
Hence both your TDD and BDD tests are valuable, as they test different aspects of your code i.e. the BDD tests ensure that a user's interaction is tested against all of the layers in your system, whilst the TDD tests cover the individual components in detail and in isolation (via mocking).
So don't abandon your NUnit tests!
To end my answer, you say that:
BDD is TDD done right
As I've explained above, the major difference between BDD and TDD is the scope of code which they cover. Dan North has a good article on this here.
NUnit and MSpec are, basically, test frameworks. They can both be used to write unit, integration, or acceptance tests. You implement the test at the right intersection of layers, behaviors, or whatever your definition is. Both frameworks support BDD-style and naming. MSpec does it up front with the custom delegates. NUnit makes it a little more challenging (you have to fiddle with constructors and setup & test methods).
You're still writing tests first (TDD), but now you're using a test framework that directly supports context/specification-grammar and behavioral testing (BDD) vs. object-structure testing.
The question isn't really about TDD vs. BDD, Arrange-Act-Assert grammar vs. context/specification-grammar, or any of the other structural differences in the test framework (one setup per context, one assertion per spec, etc), but of your skills with a particular framework!
I say, embrace your new knowledge! Do you like mspec? Are you likely to engage your colleagues to switch to mspec? Will you completely forget your NUnit skills (the API or the command-line runner)?
If you inherit some old projects or have team-members who like NUnit, the two frameworks can exist side-by-side in your solution and in your build script with little trouble. It's just not great to have many different ways to write tests and report results.
From my experience there are some cases where NUnit is still a good choice. For example, mspec currently does not support examples, whereas NUnit has TestCase and TestCaseSource. These are useful in Unit Testing scenarios, so there might still be a use for xUnit style tools. No need to "forget" anything, I think it good to be aware of all the tools in your toolbelt and choose the right one for the task at hand.
