Do You Need Cucumber or even BDD?

Do You Need BDD or Cucumber?

This is a debate that has been ongoing for a while in the development world.   

The crux of the arguments out there are have been:

• "BDD is a lot of overhead", meaning writing the tests slows us down
• "You don't need BDD, it's a waste of time"
• "Business people don't care about technical Parts of BDD or writing the tests" so "They never write them so BDD is pointless"

I'm sure you've read or heard those arguments time and time again, I know I have.

I do not claim to be a master in BDD however I'm getting to the point to where I'm doing it enough to where I'm able to draw the lines and see those arguments start to shrink more and more.

Proof

You want Proof you say! Well you got it.

For this blog post I'm focused on a recent conversation I had with a close friend who is seasoned at BDD and TDD.  I passed him this argument by Kevin Liddle because I'm truly interested in working more with BDD daily, and want different opinions out there period.

He disagrees with some arguments out there against BDD as well as Cucumber.  Because in his organization it has only been a great tool and helps their organization and has seen much success with Cucumber.js.  He is running several large development teams right now in his organization (all of which are doing BDD and disciplined TDD) and has been promoted to drive his process down to and lead rest of the organization because it's worked so well for the company overall.

He has found success with BDD and specifically Cucumber.js in his organization all the way from the non-technical business stakeholders all the way down to acceptance of BDD from his own developers across all the teams he manages.

His organization isn't some start-up, it's big.  And things have to work well.  They're driving the next wave in fact and leading their industry in terms of the awesomeness coming out and competitors are taking notice and actually using their APIs as a result!  What more testamony to design, BDD, and TDD can one get.  This is real tangible stuff at a large organization with a lot of devs.  And if anything could put DHH's baseless argument against TDD to rest, this would be a great example.

The following is a summary of our interesting conversation and sheds some light on one good sized organization and their dev teams who have seen huge value in Gherkin, Cucumber, and BDD.

Remember the ".js" after Cucumber because it's significant as you will read further below.


"BDD is a Waste of Time!"

First, this is nonsense.

If you haven't seen the value yet, then most likely one of these reasons:

a) Have you tried to or are you actually coding BDD yet? 

If you've only read about it then then why make uninformed biased conclusions if you've never experienced it yourself right?

b) You've done some BDD but did it in an organization which has made a mess of it.  

Well then of course you might view it that way

c) Maybe your organization isn't going about it in a lean or clean way:

• Cutting out QA completely from the equation
• Maybe you're tests themselves are written poorly such as including implementation details in the Gherkin which should not be there.  BDD is for high level functional requirements, not the how to implement them
• You're still using older framework that make it hell to maintain those kinds of tests and running them are slow because of that framework

For me, BDD Makes Sense and is Valuable Without Question

I've been doing some Cucumber.js for my own personal projects lately and it just makes complete sense.  BDD tests are a perfect starting point from Agile Story to starting the actual related code for that story.   Watch this video from Corey Haines, he shows you nicely how to start a new project both from a Business Domain / Priority List perspective right down into starting your first BDD tests, and then implementing the code via TDD.

BDD tests guide you.  I honestly can't think of not doing them anymore after having done some in Cucumber.js.  Because they force you to think about the business requirement at the highest level first.  It's a better starting point than taking some garble that varies from Story to Story and assuming you're getting off to the right start with just diving into your TDD tests.  Everything is clear when based off Gherkin and verifiable.

BDD tests drive the lower-level implementation.  That is they determine the direction and scope of your TDD tests once you're ready to implement the real code.  BDD forces you to think about what scenarios you need to think about first, as lean as possible, and at a high level.  And then that reduces the scope of your unit tests making the correlation of TDD tests to BDD tests a tight nit family.

A Proven Process

First off if you are trying to BDD in your organization and you're expecting Stakeholders, PMs, or QA to write any amount of code is a ridiculous expectation that shouldn't be in your organization in the first place and you are going about BDD completely wrong.  And that goes for QA too!  They shouldn't be writing BDD...period.

Business Stakeholders could give a crap about code.  They care about getting requirements right and seeing those being built succesfully and with high quality form the development team.

My friend told me BDD has only helped.  In no way is it debated in his organization, because it's produced results.  Proof first-hand in a large organization.  Because they do it right.

Quotes from my friend from our discussion

"You have to keep things in perspective.  We're talking about it in the context of Cucumber.js with Node.js, not older Cucumber frameworks.  Cucumber.js and older Cucumber are not the same in terms of speed to code and run those tests.  So the speed argument doesn't apply to what we do here.

As for the argument that business people won't write Gherkin or that Gherkin is a waste of time isn't true for our case.  

That's because all our business people have agreed as a standard to write acceptance criteria in Gherkin format right into their Jira Stories and we don't ask them to do anything other than that, that's where it stops.  That's not difficult for them to do, and they like it!  We don't expect them to write any code.  In fact we don't even really have QA anymore, we've trimmed QA out of testing completely and have very few QA resources period.

Our Engineers then simply take and copy the scenarios that are in Gherkin format from those Jira stories that were written by the non-technical managers and PMs, and and write a BDD test for them and it's not a big deal to any of our developers.

And Since it's fast to write tests and setup Cucumber.js over Node.js, there's not a problem with it being slow to run or code at all...so this is not the same as using older Cucumber to do this and so it's not a problem for our business or devs and it works great for everyone here.

Our team has been doing it for a while and don't complain about it…they actually like doing it.   Where teams start bitching and stuff is a dirty little secret.  It's usually those teams who have QA staff.  And the QA staff is essentially doing half of their testing for them.  Once you remove the QA staff from the equation then it's different.  

You tell the engineers they're responsible for the quality…then all of a sudden that automation makes a lot more sense to those engineers.  So that's the piece you are not seeing in those arguments also…is that most of these engineers tend to have QA resources as part of your team and is why BDD is getting a bad rep.

We then run our versioned automated functional tests (Cucumber.js BDD test suites) every 30 minutes against all our environments all the way up to production on our apps all the time."

That's what Gherkin is For

Given I am a user
When I go to the main landing page
And I see that there are some events scheduled for Metallica

If you think about it, how many times are you in an iteration planning meeting and you're trying to write some of the acceptance criteria and your description and details around that varies greatly in who wrote it in terms of how it's written...it's usually a big mess with no structure.  In Story A someone wrote it in a nice clear concise manor.  Fine.  In Story B for the same product, same iteration wrote too much, or wrote it messy because they have a language barrier, or just don't give a damn or just are not very good at writing to begin with.  That happens, because we are all different, we're all human.

But when you have your business stakeholders write the criteria all in Gherkin right in your story it just make complete sense.  That's the whole value of Gherkin to begin with.  A template to write clear and concise functional requirements anyone can understand and think out in a consistent and very clear manor.  

So stop having different people use different templates (or no template! even worse) for writing the acceptance criteria in your user stories.  Just use Gherkin style.  It's just too easy and it makes too much sense not to.  Be consistent.  Be clear.


Developers Take Gherkin and Write The BDD Tests Themselves, not QA

Yes I said Developers...not QA, nobody else.

No this is not far fetched and no this doesn't slow down the team.

Your developers (not QA!) simply and literally copy that Gherkin typed by your business owners from the stories and when they start on implementing a story, first they they do is create the Cucumber.js BDD tests starting with the Gherkin themselves and don't even question or complain about doing so because it just works.  

You start with the Gherkin written in whatever Agile Software you're using to create Stories, have the business people write that gerkin as acceptance criteria in the stories, then have engineers take that Gherkin and write the BDD tests.  After you have your BDD tests written, they serve as a guide in the next step which is to start writing the TDD to implement the real code for those BDD scenarios.  It's very much a controlled, clean, and fast way to get things done.  It's a lean way of coding and getting shit done.  

There's no going to QA or having an expectation for anyone but the developers to start implementing the rest that's under that BDD.

Cutting QA Out, Are you Joking?  You Jerk!

This is not a new concept.

It's not theory or wishful thinking for some organizations.  It's actually really being done more and more across organizations today as they embrace more Pair Programming coupled with TDD and figure out how to make BDD work.

When BDD is working right and is working for non-technical owners, that's where things start to change.

It's because some organizations utilizing BDD have gotten to a certain point to where their BDD process is driving things and working for all involved and that when oupled with TDD and simple design, everyone starts to see a very low bug count and even rare corner cases aren't there much anymore on all apps being developed or new features added or changed.  So you end up literally not needing to have that extra layer of a QA department bogging you down.  It's straight up business owners to devs.  The Business owners know what needs to be done to meet a requirement for the business and it's getting done by the developers effectively.

Developers code the BDD for the Gherkin, and develop the code via TDD.  There's really not much more to do and really not much need for much if any QA after that when everything is aligning this well in an organization.

Obviously Can Also Use Other Frameworks

I'm not completely biased toward Cucumber although my wordage might indicate that in this post.

Note that there are other test frameworks such as Mocha.js where you can kinda do the BDD and TDD all in one roof.  Currently I'm trying to use Mocha.js for the TDD tests and Cucumber for the BDD on my projects.

But I'd still see some value in using Gherkin-like wording in Agile Story acceptance criteria.  And then implementing the code for that by devs.  You could use other frameworks outside Cucumber is my point.  It's just that by adding the Gherkin-like wording is still valuable, clear, and maintainable at the story level when written in your Agile Stories during iteration planning.

Conclusion

I think the most important points coming out of our conversation were the following:

1)  Just have your stakeholders or PMs write the Gherkin syntax in the Agile Stories as the Acceptance Criteria, no coding required

2) Devs should be picking up the Gherkin from those stories and writing the BDD tests themselves, not QA

3) It's been proven to be a very Lean way of producing code and satisfying business requirements

4) Cucumber.js and Node.js changes the ballgame on the old argument of Cucumber is slow or time consuming for devs

5) The teams who have QA doing the BDD tests are actually putting up a wall to getting the actual work done and tested

6) QA is being removed from the equation more and more entirely, because bugs are low when BDD and TDD work well and you have clean, testable, and maintainable code as a result of that and keeping things simple / minimal / lean


Be Careful

So be careful of the general arguments out there against BDD in terms of if you need it or not.  And in my particular conversation, revolving around Cucumber.

Things are changing in both the BDD framework scene these days, and how BDD is being done.

Arguments that have existed against BDD and against Cucumber in this case are becoming stale and no longer true in some organizations.

TDD - Don't Worry About Code Coverage In The Beginning

I came across a Quora question today on TDD and amount of Test Coverage to aim for. 

Here was my response.  But before I dive into that, let me state that TDD is an ongoing continual process of learning.  There are critical things you just can't skip, or things you have to become aware of and over time learn how to "do it right" and there are indeed right and wrong ways to go about it.  It's always a continual learning process as well, even for seasoned TDDer's.

1) People new to TDD or misunderstand it may be missing of the point of TDD Altogether

It's not only about tests and test coverage percentage.  

Sure you get coverage and confidence but it's even more about how TDD guides you and helps you to see things in code that you would not be seeing if you were to test after new code.  What you should be focused on is learning how to TDD, and striving to create clean, simple, maintainable code before you even think about % of test coverage you've got.

Also, there are a lot of teams out there who default to the conclusion that TDD == Just Unit Testing.  As a result, they immediately then conclude why should we even do TDD? We just do tests after, same thing, same effect...and after all we're "doing what works for us" so skat...

The "do what works for us" is fine and I believe a team should do that, but it's often used as a cop-out and reason not to try or learn and adopt TDD or in some cases doing to TDD what people have done to Agile which is to skip the goals and principles thereof.  That a team thinks they are doing TDD but some on the team think it's ok to skip one or more of the 3 laws of TDD (e.g. we can just skip the refactoring step because we can do that later because someone is breathing down our neck to get this feature out).  

And that's where the misunderstandings and assumptions start.  "Oh we have code coverage and we don't even need TDD! ", the party has started.  Or "TDD is the same thing, it's just adding code coverage, so we just add all the tests after".

I'm sorry to tell you but you missed the point of TDD and you don't understand it quite yet.

Such as:

• helps you to produce leaner code because it forces you to strive for simplicity and forces you to be more simplistic during the creation of tests and production code as well as the refactoring step which forces you to go back and make things even more simplistic (means you are not skipping the refactoring step as well)
• keeps you much more close to your code at all times in that it keeps you more aware and critical of your code at a micro level when you practice TDD

• It's about verifying if your tests are valuable during each step of the way because you're getting that feedback early and getting it right after you get your test to go green

The level of feedback and guidance when you code via TDD is way different in my experience.  You're much more critical of your code when you go very small steps with TDD and adhere to the 3 principals.  The 3 are a tight loop that works wonders...and you do not skip one or more of the 3.  Only until you do it, will you understand how powerful TDD is and how much it's really making you more efficient as well as your team once you get used to it and know how to do it right.

2) High Code Coverage Doesn't Automatically Translate to Value

Why?  What if your tests suck?  Just because you have code coverage doesn't mean your tests are good ones, or the right ones. 

In fact you could have wasted time adding all the tests after that were not valuable in the first place whereas you would have saved time if you had Test Driven your code in the first place and end up with more tests that are valuable.

Now TDD helps with that, it helps because along the way when you're doing test first and driving the code, your tests are more likely to be focused, smaller because you force yourself to stop once they go green, and find out immediately if they are valuable in that they give you feedback you can trust because you're also running those tests very often throughout the coding of a feature.  

But even with TDD you can add tests that are a waste, tests you can't trust, tests that are doing way too much or testing the wrong modules of a system that don't need to be tested, and the list goes on...it's a matter of practice and experience and making sure you run the test suite continually as you code more and more production code.  It's just that TDD helps you to have less of those useless tests because if you are following the 3 laws, and adding tests as you go,  in my experience it's likely you'll have less of those invaluable tests vs. valuable.  Value means you are getting immediate feedback you can trust and the feedback is based on micro

3) You have to be careful with Wonderful Metrics

Extending point #2, Metrics are wonderful tools to gauge what's going on but when being reviewed and gauged in the wrong hands, they can also push for the wrong goals in the beginning, miss the point,  or push for stuff that's not providing true value for the business.  

Example:  At a previous job, all the team cared about for the majority of the time was meeting numbers for Goals and Objectives, referring to the code coverage for the team as a whole.  And didn't want TDD...they  figured it's a waste of time because "oh we know what TDD is already".  And most on the team were completely happy with always promoting and tacking on tests after finishing new production code.  

There was no real push for the team to learn TDD so that the team could go through it's motions correctly and see its true value.    Some even bluntly refused to do / work hard at learning how to do any unit testing period regardless of trying to get a team to adopt TDD...so the overall base code coverage was minimal in the first place since half the team refused to unit test, the code coverage might have been 80% as only a couple on the team decided they were worth while, so really that goal in the end only covered 20% of the overall code being produce on the team...and we still didn't know what % of the code truly gave us value.  We knew that tests were helping but we did not now what code coverage was a waste and what code coverage were not valuable or trustworthy.

You may see bug count go down but what % of your code coverage is or is not contributing (not useful/trustful) to that the lower bug count, and what % of missing code coverage are we missing which could make that bug count go down further.  There's way more to read into testing and especially when you go the Test Driven route.

4) You can over test

Again this comes with experience in terms of recognizing when you are doing so..testing things that don't need to be tested and adding coverage later than you didn't need.  You may not realize it until you've done TDD for a long time.   And as a result what you can end up with is having is a nightmare to where you change a line of code and have to change 200 tests, many which are not even directly related to the line of code you just changed, because your test suite is too focused or focused on stuff you don't need to be adding coverage for.

5) I find that when I Test Drive all new code, I usually end up with higher test coverage to begin with 

Rather than tack on a ton of tests after new code and hope and pray they're even valuable or wondering if I am testing the right things and that I'm hitting some goal of code coverage, I find that I end up with at least 70% code coverage most every time I TDD a new feature.  

And I'll humbly admit that this is only because I've worked my butt off to try to learn it and at the same time had the rare opportunity to pair with people who already know TDD well and learned from them how to do it the right which is why I end up with a higher percentage of valuable tests, higher test coverage, and can trust them and testing the right things but it's always a learning process...and I'm continually learning how to get better at it and always will be.

Conclusion

In the beginning, it's better to forget this code coverage goal and to learn how to do TDD right and to get comfortable with is so that you can see it's benefit which is where it starts to get fun.  This is only done through persistent practicing of it and if possible be practicing it with the right people.

When I say "right people" it's not to imply snobbiness.  It actually means the opposite, to find people who already know it well and had success with it and learn from them because it will save you a lot of pain and you'll learn ten fold and save hours of wasted time reinventing the wheel and prevent you from making common mistakes that newbies make that a seasoned TDD developer can point out and prevent you from doing or answer many questions as you go about pairing with them.  

The worst thing is for a business or team to try to become a TDD shop when there is nobody on the team who is seasoned already at TDD who can help pair and train the team for a good period of time first, and then at the same time, your dealing with the boss who just cares about goals of % of code coverage as the most important metric to deliver back to upper management for the end of the year.  You'e just going to delay focusing on what's really important, getting TDD right and seeing truly it can do for the team.

Wait till you get comfortable with TDD, and you learn how to write better tests, and start to see its value, then start worrying about coverage %.

A Journey to TDD - Part 3 - Creating a TDD test with ReSharper

To learn TDD takes time.  It takes time to learn how to do it, but also to do it in the way that is efficient as possible.  So that shouldn't stop you from doing TDD.  That includes using and learning tools like ReSharper and keyboard shortcuts to make generation of production code fast.  VERY fast.

Again when I talk "production code" in the context of TDD, that is code you create AFTER you code the lines in your Unit Test of things that don't exist yet.  "Things that don't exist" could be anything from the core class you need, new methods in that core class, or properties that you want to populate as part of your TDD Unit Test.

So I wanted to find the fastest way to generate the classes, methods, whatever from my Unit Test...that is generate the stubs that do not yet exist as fast as possible.

After researching a bit, I found that there are 2 ReSharper keyboard shortcuts that you'll need and that's literally it!  Those are the following:

• Alt + Enter
• F6

At first I found the Efficient Navigation when doing TDD/BDD with ReSharper video from JetBrains but it's very old.  It talks about TDD with R# but that's ReSharper 5!  Apparently they have not updated their videos in 10 years or so.  While most of this is still valid, I found a better option, F6 for the moving of the cla

Anyway, I found it, was just what I was looking for.

Later, after applying Alt + Enter and Ctrl + Shift + R (refactor menu), I found yet a quicker way which was just F6 for the refactor menu.

So lets take a look at how you would apply this in Test Driven Development because that will also show and explain how ReSharper will help you in this process once you get the keyboard shortcuts down by habit just from routine practice.

Using the Red, then make Green, then Refactoring principals of TDD, here's what that looks like and how I used the shortcuts to perform a typical creation of a unit test against a use case and necessary classes related to one particular unit test:

1) Always Start with a Use Case (Story) to drive what tests you need

Eventually this will just come naturally through time as habit, but intil then, be sure to keep reminding yourself and try not to forget that TDD tests themselves are a form of living documentation.  When a team looks at TDD tests they should feel confident that those who created those tests did it with Use Cases driving them...and that they are not some abritrary guesses.  

So you should feel good that with TDD you have guidance.  You don't just blindly start off guessing what you may need for "possible" requirements in the future like many devs have done without TDD and who create much more code than is needed in a lot of cases (wasted time).  Instead, you don't need to guess where to start.  TDD tests are and should be driven by Use Cases (Stories)

Your test classes should therefore act as documentation itself.  Meaning anyone should be able to go into a test class and it can be viewed as a footprint for business requirements.  Tests in your class were written for business requirements so the intent and reasons why those tests are there should read like documentation.  Meaning your test names should be clear on what they are testing.  And each unit test has a direct relation to one or more Use Cases that drove the creation of these tests.  So these tests are the business requirements literally from use cases.

Also all your tests serve as a form of documentation to other devs.  If you want to know how to call something, look at the tests!  They show you exactly how one could call a certain method in many ways as if you're coding via TDD you'll have a lot of tests per method usually.

And as a result, you are driving your team to create LEAN code.  Since Unit Tests are driven by Stories and you are to make sure unit tests are as small as possible each, some seemingly ridiculous to newbies, they are not too small.  Because by creating small tests, you are thinking about the parts you need to satisfy those business requirements.  And a unit test by definition means you test ONE very small thing.  That could literally be testing to make sure a method does not return a null instance or doesn't return an empty string.  All these kinds of little tests are things that could go wrong while you code methods and classes for the use case.

And remember you aren't going to know what tests you need instantly even if you have a use case right in front of you.  One of the good things about TDD is that it forces you to think about what you need for a use case.  So you're only creating the code you need, at its leanest.  Just enough code to pass the tests that make sense to support the business use case.


So lets start with a hypothetical Use Case:

    Figure 1 - a user story in Jira

So this user story has a couple tasks (we'll only talk about the first two):

• create an initial Web Service class stub
• create some method stubs we think we'll need to support facilitating calls to various payment processors
• Create some utility methods for parsing proprietary XML, sending API requests, creating request tokens, etc.
• ....

So this is a business requirement.   Tests we create should make sure our code is satisfying that business requirement.

The first two tasks are dependent on each other so our tests will naturally involve the two anyway (you need a service and you need methods after that)

1. We'll create a new PaymentServiceTests.cs class to hold our unit tests for this service
2. We'll start thinking about what this service should do/provide, if it needs a constructor and some initially wiring up on a constructor for any reason, and how it might start out. This is the part of TDD that forces you to think about what you need now and at its leanest.  This is the best way to discover what you need based on the Use Case
3. As we go, we'll naturally start thinking about and as a result discover how we'll implement the production code in these methods and class to make our tests go green

Now Lets start on the Tests to Support these requirements

First lets create the service Interface.  Note we could also be creating a class but we'll do it by an interface for now since that's normally where I start when I create a web service because I start thinking about what methods we'll need for the service and there are several reasons I'm using an interface here that I won't go into in this post

To go about this, lets start creating tests in our PaymentServiceTests.cs class:

Usually most TDD tests start out with checking the absolute very basics.  We're talking about stuff like making sure you even have an instance of the service object itself.  When you do TDD again nothing is too small to test.  It may seem absurd to test something like a valid object but you'd be surprised that these things can fail at any time in the future if people start changing the implementation of the class, initialize it wrong, or whatever...

So the first test simply checks that we have a valid instance (object) of the service we want to use, in this case our PaymentService.

    Figure 2 - our first TDD based unit test for our new PaymentService and using 
    Roy Osherove's convention of method naming as well as comment guiding parts of the test     code inside (Arrange, Act, Assert)

Because I want to base my service off an interface, we know we'll need an Interface AND a service class that implements that interface.  We also know we'll need methods in both places right?  A method stub in the interface and method implementation in the Service class. 

(Some may argue we don't need an interface here but I can argue some reasons that we benefit from having one here.  I'm not going to debate that now, so just follow along...the point is to get a test of how to start TDD which again I'm learning as well but figuring out more and more every day at work.  We do not have a certified TDD guru on board so we're all in the same boat, learning and trying to do TDD right.)

The Service Interface will house those methods that we want to expose publicly to the client/consumer of this Web Service.  In TDD you want to only unit test public members for several reasons that I will not get into in this particular blog post.

The Service Interface is also where we will house and define the WCF or other specific attributes that the methods will rely on.  We are adding attributes in this case because we are creating a RESTful WCF service.

So if you look at the test above, I thought to myself ok, at the very least, we need a valid service instance before all else.  This is typical in the TDD world.

One interesting thing to note.  For now, I like the approach of creating the assertion first.  By doing so it makes me think about what the test expects as an outcome to support the use case  

Then after creating the assert, going backwards to create the non-existing class or methods and code as if they are available but we know they are not that the assert is using.  This is called Failing First (going Red first).  Meaning you code as if those interfaces and classes already exist but we know they don't.  That's ok and what you want to be doing, it will feel awkward at first but you will see the beauty of this later as you get more practice with TDD and start seeing the light as to why this is the first thing you do if you are coding via TDD principals.  

Again, don't be tempted to go create theses files (class and interface).  When you do TDD, You want to generate the actual class and interface files from your test.  And this is where ReSharper will really automate that and help you do it quickly.

So first I create the assert:

    Figure 3 - initial assert to support this Unit Test.  This unit test will be one of many to                               come as we create more tests support our Use Case
    
   This asserts says I expect that I always have service object instance to work with at the very     least.  We need that do do anything period if anyone wants to start using our service.

Next, lets start creating production code (implementing the actual method, class, interface, etc)  to support the assert:

    We needed to create the variable called  serviceInstance.  To do so, that means we'll 
    need both a ServiceInterface and related Service class that implements that interface.  
    Again the interface just abstracts out WCF specific stuff and also defines the public 
    contract which is very common when creating WCF services.  We could define a public 
    contract for WCF with just a plain class, but I have my reasons for 
    doing it this way, there are many benefits in this particular case.

    So I just started right in creating the variable as if everything exists.

    And what you end up with is red invalid service and interface references.


Next step is to create the production code.  Meaning we need to start making this test green.  Putting another way, we need to make this test REAL.

Now here's where ReSharper is very handy.  There are a couple things we want to do to accomplish creating our interface and test class here:

• We need an IPaymentService.cs interface and a PaymentService.svc.cs class
• We need to be able to create new files for these
• We need to be able to decide where we want to create those files as we don't want them located in our Test itself
• We want to be able to reference the namespeces for those new classes in our test project so it knows about them (in other words we'll need using statements for these at the top to recognize they exist)

Now the nice thing about ReSharper is it helps us do this very easily and quickly which othewise would take minutes.  

Here's what ReSharper can do for us in response to the steps we'll need to take in the list above:

• We'll need only 2 ReSharper based keyboard shortcuts already built into ReSharper to assist us
• ReSharper will automatically inject the using statment in our Test class after all is said and done (you don't even need to think about it, nice right?)
• Optional benefit:  I like using the ReSharper test runner, which to me is more powerful and easy to use rather than MSTest runner or NUnit's crappy test runner

Now here's how we'll finish the rest efficiently with ReSharper:

First lets create the Interface class stub and file:

Place your cursor at the beginning or end of IPaymentService and press Alt + Enter.  Nice right?!!!  you immediatley get an option instantly to create a new interface:

This will create the interface stub in your test class:

    That was Jimmy Johns-like freaky fast right?  Huge time savings right there, no excuse to 
    say TDD is slow (well after you practice and get this down pat that is)

Ok and now lets create the PaymentService class stub, same deal, Alt+Enter:

Nice right?!?!  but wait, look again.  ReSharper also helped us out by the fact that it knew the context.  It knew not only to create that class but to automatically implement
IPaymentService based the context of the line of code where you told it to generate that 
class from.  Awesome right?  You should be saying damn straight...because this is the kind 
of stuff Visual Studio doesn't do for you...stuff like this that saves you so much time.  This 
goes beyond basic generation, this is smart generation at the same time saving you a few 
more steps.  ReSharper is smart people.

Finally you say to yourself, well that's stupid, we don't want this here, these should reside in our WCF Service project.  How can I move these and also create a new file at the same time?

Again ReSharper to the rescue.  All you need is F6 on your keyboard.

All you need to do is place your cursor at the beginning or end of what you want to move, this being the PaymentService class and choose "Move to Folder":

   Then this brings up a quick dialog to allow you to finish that move and also specify what 
   project and where in that project you want to move this and also create a file for this:

    Ok great.  However it defaulted to the location being our current test class.  Lets change         that.  Backspace a little and ReSharper automatically adjusts the list to show you more and     more up the tree of projects and folders in your solution:

    Ok cool, but I want to go all the way back to the root of my solution and choose a different 
    project.  So instead replace it and type in the name of your project and you'll get a broader     list up the stack to choose from.  Then just arrow down to which one you want:

   Once you select the right project, then add a slash "\"  at the end and it'll start showing 
   you the folders within that project to choose from:

    OPTIONAL: Also notice you could use this icon at the top right for another way to visualize     the solution stack as well:

    
Anyway, I've told it where to generate the class and now it just did.  It created the .cs files and placed them where I told it.  

I repeated the same set of steps we just did to move the Interface as well.

Now our Test class is clean again and just contain tests:

And look!  And since I use the ReSharper Test runner, it automatically detected what Unit Test Framework is on, so it added a nice little icon to the right that we can click on to run the test:

And results shown in the ReSharper Test Runner shows our test now runs green!  We've just created just enough production code to make this particular test past.  So we've just created what we need and only what we needed for that test.  We're creating LEAN code and that's just one of the benefits of doing TDD and following its principals in order.

Actually I had to change it up in the end to make it go green, just an example of how TDD makes you think about stuff and make it work

Tools used in this example:

• VS 2012
• ReSharper 8.0.2
• My Brain and thinking based on the Use Case

Till next time, work hard and learn TDD ok?  Stop Making Excuses. It's worth the work now, you'll benefit beyond your wildest dreams later once you get this stuff down and it becomes habit / no brainer later on.

A Journey to TDD - Part 2 - Getting Proficient As Possible as Fast as Possible

On our quest to be a TDD driven team, one of my colleagues had a great suggestion.  That is to watch a video together once a week while we also try to code TDD.  I totally agreed as I was thinking the same in that we should all be watching about basics first to get a foundation in addition to just "diving in" and some of our guys have not had the time to watch videos what I really feel is important for us to watch.  The rest of the team thought that was a great idea as well.

Our boss also started us doing some Mob Programming.  It's pretty neat.  Our team doesn't don't do it all day every day to the extreme whereas some places do as it's not our methodology.  We are a SCRUM based agile development shop, but we are stealing that idea and applying it for an hour taking 2-3 times a week, bringing in the entire team or immediate devs on your project come together in a conference room and work on real production code together via these Mob sessions.  

In our mob sessions, one person drives.  We rotate the driver every session so everyone is forced to be a driver.  Then we all start to code real code together.  Think about is as like one huge XP session where production code is getting done and everyone is learning at the same time.  If you can't make a session it's alright, it's a come as you want basis but usually we have several devs show up to at least a couple sessions a week so we end up being productive in it.

As a teammate, I'm also trying to contribute by helping myself and everyone up to speed and doing TDD as much and as fast as possible.  To do this though, we know that it will take time to get it right as we are all new to this.  We also need to keep in mind that this is not just a technique, this is a total change in mindset and attitude when you do TDD and that there are principals that when followed, work.

Anyone starting a team out doing TDD might question some things about it or how you do it.  But we know there will be a period of learning why and how and that yes, there will a cost in that there will be slower development going on but that there will be a threshold met when we get used to it and able to fly with it and it will be a no brainer.  This is when the business starts to see fast and quality end results out of their development team to a degree that they have never seen before.  But this won't happen unless you follow the 3 principals in order and refactor your tests to be DRY as stated in the diagram during that process.

Principals of TDD have been proven and successful for a long time now.  This is not some theory or "achedemic" set of rules being forced on you or a "we are doing it because everyone says we have to do it this way" as some people might view it.  These are not principals you say "oh we don't have to do it quite that way, we can write tests after and come back and write the test".  These are principals that depend on each other and depend on you doing it in the right order.  If you don't adhere to failing test first, etc. then that's not TDD and that will not provide you the benefits you are seeking.  If you are not writing failing tests first, then please do not call it TDD.  This is not a discipline you just take for granted or twist and turn into your own way of doing it.  There are 3 principals.  If you force yourself to figure it out, understand it, practice it and follow it as does all other TDD shops who have been successful at it, you will reap its benefits.  If you do not, you will eventually end up with a mess plain and simple and sadly will never know TDD as it was meant to be applied and never reap its benefits.  Having unit tests is great.  Driving new code with TDD is awesome.  Just stick to the principals when you do it is all I'm saying.

As a side note, I've been on so many teams in the past who get lazy and write tests AFTER for any new code, and it just ends up in a huge ;pile of shiza, and lot of inconsistent useless Unit Tests that test more than one thing, test things that do not relate to the use case, as well as high confusion over WHAT should be tested after the fact.  Or I've been on teams that do not see the value in unit tests at all and will do anything to deter you from spending time doing them.  

And let me say sure, obviously you can't apply TDD to all of your code as you will have legacy code as well.  But if you are test driven, eventually all new code will be created with this technique and mindset and, you will no longer have to be wasting your time wondering if you are writing the right tests or if your tests are too big, etc.  Because when you can do TDD when writing tests, as you code, you are forced to THINK about what you are coding and how you are meeting the business requirements and again, failing tests first coding classes and methods that do not exist yet force you to think about what you really do need (simplicity) for that business requirement.

That hardest part is to change people's mentality but more importantly devs don't get that your tests should be so freakin small you think it's ridiculous.  But that's the point.  A lot of devs typically in early stages will say do we really need that many tests and to spend time writing so many?  Do we really need to test something that small?  the answer should always be without question YES if you are buying into the technique and mindset of TDD.  Otherwise you loose its benefits.  You should have many tests...small as hell, testing one thing, and even if you think it's too simple to test, that's not the mentality you should have in TDD.  You will have several tests for "a" method in a class.  There is no "too simple to test" idea or concern here.  A "unit" is testing ONE thing.  And that ONE thing should be very very very very small.  You have to get that mentality in your head and accept it. For me it makes total sense and I don't have that conflicting urge not to do that.  Personally I want a lot of small tests, ti just makes sense and I know it's gonna help find bugs very quickly and that you can trust your tests because they are so small there is no doubt about what to call your test, or that you are introducing bugs into your tests.  You will write tests and over time get good at it and the automation of all this will save hundreds of thousands of hours each year for the dev team and the business in the long run.

So going back to our video sessions. The first video I suggested which we watched this week was Unit Testing Best Practices with Roy Osherove.  

And the reason I suggested this one as opposed to jumping right into TDD videos was because 
it's just as important for you as a developer to know traits of what makes good unit tests (TDD or not).  

This video by Roy is not about TDD although he does relate to some TDD in it.  
But it's more about how to write good tests.  I felt that it would be a good suggestion that we take 
that step backwards and then into TDD videos after and I think the team liked it and it was a beneficial video 
to start with as far as I could tell.

I also suggested the next video to be the following from Uncle Bob to be Clean Code → Episode 6, TDD - Part 1, as I bought it tonight and thought it was very good.  He explains the benefits of TDD better than any video I have watched yet and also drives home how important it is to STICK to the 3 principals of TDD and why you should not deviate or mess with the formula.   It addresses a lot of concerns people who are not experienced with TDD have, common responses you get (oh it'll take too much time to code all these tests, yada yada) that try to push TDD out and keep it from penetrating your development team as a way to develop code. 

We're having fun as a team, but more importantly learning together and a unified goal to create better code, have test driven code that will save us a ton of time later on and our boss is totally on board and motivating that drive.   That's one of the problems in our trade...finding a good team and a good manager.  That doesn't always just come easy as a lot of my friends have experienced the same.  So point is you have to have a manager who is invested and passionate on improving the business and the team.  

I think this is the kind of team every developer should want to work with.  Who wouldn't right?  If you are not working for this kind of team then maybe you want to seek one out.  It may take a long time to find and a dime a dozen but they are out there from what I've learned.  It's fun, we get stuff done, we know things will improve over time with TDD and cleaner code, and we know as this progresses, if we stick to our guns, we'll get to go home to see our kids and wife without worrying about shit at work like fires, meeting deadlines..stuff like that which makes your life hell on some dev teams I've been on in the past.

So taking an hour out as a team to watch videos from some great people (Uncle Bob, Roy Osherove, etc.) it's great parallel step as a team toward TDD development as we also do Mob programming together.  

Also we've decided to try to attend a Dev events outside of work together as a team (or at times we may even take a half day of work to go to these).  The first session we attended was one by Uncle Bob that you can find and watch here:

While we are not 100% an XP based agile shop (again we're primarily SCRUM) we still also do pair programming as well quite often in fact.  We will go to each other's desks and code together (one codes, one observes) and the productivity level increase is just astonishing and is the only way to go on any development team as far as I'm concerned.



So as we start to do more TDD together, I will post Part 3 of this series which shouldn't be too much longer...we're gaining ground more and more on this adventure.