Different Ways to Run WCF Services Locally

Today, I just wanted to post the different ways you can run a WCF service.  There are times you want to run them certain ways so here are a few to think about:

First Option:   Run it in full blown IIS

Honestly I think even though this is more work for each developer when they initially want to just run a service project the first time, rather than use IIS Express, IMO it may be worth the pain to have to set it up in full IIS locally yourself ..because IMO it's just good for devs at all levels to know IIS inside and out and many devs still do not which I think to myself why would you not want to.  

So even though now I use IISExpress, in the past I liked setting everything up in full blown IIS personally...and that's forced me to really get to know IIS and know it well through the years by doing this.  I never used Cassinni either for this reason and also it was a black box and I do not prefer black boxes.  In IIS you can solve any issue with hosting whatever, you have full control.

So doing it a more manual route to me forces you to learn IIS, because that's how you're going to deploy it anyway to other servers.  Why use something like IIS Express if that's not how you will be hosting it in a real environment, I just don't see some shortcuts as being a benefit in the case where devs are totally reliant on not knowing much of IIS at all.  For instance ASP.NET web controls and Web Forms; sure they let programmers program easily (piratically pushed us to be "dumb" programmers), but we found out years later that MVC was better and forced people to LEARN code.  I feel the same about IIS and running stuff locally.  But that's just me :).

Second Option: Run it in IIS Express

v    So to do this, in your WCF Service project, right-click your service ([MyServiceName].svc) for and choose to open it in the browser from the context menu:

This launches the service automatically in IISExpress as you will notice if you go down to the running task icons next to your clock in windows:

This also then continues to open up the service endpoint in the browser to the default service page:

Third Option:   Run the WCF project straight up using F5

This is a “WCF Service Application”.  That means by default it’s set to run in a browser and by definition of this template, has a web.config associated with it. 

So if you just want to run the service quick, by itself in memory in the background, and don’t want it to open a browser (which does NOT run the service it appears), then go to the properties of your WCF service project and tell it not to: 

By doing so, then when you set this as the default startup project, it will indeed start the service so that you can go back and my unit test above will run GREEN.

Fourth Option:   Run the WCF project straight up using F5 -  but set Project Startup Priority for the entire .NET solution

This might be better for you as you can tell it hey, I want to run my service service in memory (not through IIS) AND also run other projects like another web project, etc. in your .sln (solutoin)

To do that, just make sure that the service project is started first...as other things might rely on it such as your web project, etc.

Do this by going to the .sln properties in VS and set your startup projects and order:

Then try pressing F5, you will notice that now, the web service will run, AND for example an ASP.NET MVC project will also launch, so you have both running now.

Using the ReSharper Test Runner for Unit Tests and TDD

Are you using ReSharper?  If no, ask yourself why not.

I have met devs who swear by ReSharper, devs who have never heard of it (scary), and then devs who keep putting it down due to in some cases pure ignorance or typically some brief past experience with it.  I am in the boat where I swear by it because it just provides so many efficiency gains that it's a no-brainer not to buy it for yourself and use it.  Even if your company won't it's totally worth buying your own.  One of those huge benefits is the ReSharper test runner that's included in ReSharper.  Remember people, ReSharper is not JUST intellisense.  It has a ton more benefits such as code hints and a lot more than even that to help you as a developer shave time and learn as well as you code.

Now when I say ignorance to those who keep saying ReSharper is bad, usually people who say this typically give these reasons:

• It's slow
• It's unnecessary, VS Intellisense has what I need
• It costs too much
• I don't need Intellisense I'm a hard core programmer, I code without it :)

I say to each of these nonsense!  And I will debunk those:

• yes it used to be too slow 8 years ago when ReSharper did have some slowness issues, I even remember when I was frustrated with it at one time.  But that issue has resolved been resolved a long, long time ago by JetBrains
• It's unnecessary because you use VS intellisense?  Ok that's fine, I'm not here to dictate what works best for you.  I'm not saying ReSharper may 100% be fore you but I bet you haven't tried it or tried it long enough to realize all the things it provides you as an add-on that VS 2010, 2012, whatever version does not currently do or do well.  I can blog post about that later on, which I plan on doing as well
• Costs too much?  I am ashamed that devs expect everything for free and willing to sacrifice making life easier by refusing to buy a tool for $100-$200 which IMO is probably worth $600 considering what JetBrains has done. That includes Webstorm as well, awesome IDE that they sell for ONLY $50.  The fact is there are tools that provide just too much benefit not to buy yourself if your employer won't divy up a lousy $150.  In the scheme of things $150 is NOT a lot of money.  Also ReSharper now gives you free upgrades for an entire year.  Then after that it's only $90 to renew it yearly and again you get free upgrades for another year and so on..not a bad deal IMO considering how awesome this tool is and the feat it took to even build it
• I won't even comment on the last bullet point, it's not worth my time, that's ridiculous

Now back to what you came here for, more about ReSharper's test runner.  I've always been an NUnit guy for unit tests.  I have although used MSTest in the past 2  years.  Regardless of what framework, I use ReSharper's test runner.  You can always use ReSharper's test runner as an alternative to most of the unit test framework's native test runners out there.  We know NUnit's test runner sucks, but obviously not the framework.  I think I tried MSTest's runner once and it didn't even compare to the ReSharper test runner (at least at the time, which was trying it 2 years go).  ReSharper's test runner makes it convenient, detailed but not too detailed, and simple to use.

Now lets take a look at what the test runner looks like and a few things it'll provide you and show some screen shots of that happening when writing your tests.

First, know that ReSharper will automatically pick up the fact that you are using a framework like NUnit or MSTest just by including the using statement to it in your test class.  Once ReSharper sees this, it'll provide some nice icons that you wouldn't otherwise get with vanilla Visual Studio when working in your test class:

Notice the icons point out in the orange area in Visual Studio.  When you start decorating your test class and test methods with attributes such as [TestClass] and [TestMethod] (or [TestFixture] and [Test] in NUnit), little round icons show up.  Those are a nice convenience in that they allow you to click and run a specific method or all methods (if you click on the icon at the class level) in your test class.

Also notice the red bulb icon..   This will allow you to create instances of those types that have not yet been created (i.e. your TDD test goes Red).  Those instances will be created within your test class.  You can also right-click the type and choose to create a new class for it which will generate a completely separate .cs file for it...which is probably more desirable.

Now lets look at an example of running a test.  I'll click on the first test and run it so we can see the test runner pop open automatically right within Visual Studio:

It gives us the option to run it or debug it.  If you want to step through your test while you run it, add a debug point first and then go back and choose the debug option here and it'll stop at your debug point once you click on the debug option here so that you can actually run your test but also step through it at the same time if you wish.

I'm just going to choose to run this method (not debug) for now.  Note: be aware that this is not a finished TDD method in this screen shot, you're only seeing the first line of it..no asserts are there yet.

When you run this test method, it'll will show the Resharper Test Runner Pane at the bottom of VS for the first time, and the results of the run:

So now it ran and you can see that this method succeeded.  Also notice all the nice bells and whistles the runner can offer you.  

Back to the test runner.  Now lets show a TDD method where you are specifying a type that doesn't yet exist so your test is Red (does not build because of it):

When I try to run this unit test, it'll fail because the class InventoryService doesn't yet exist (as this is how you do TDD, you fail first, then create it to make the test go green by creating the actual type after).

Here, we've said ok, I need to make sure I can instantiate a class that doesn't yet exist...that is, the service class we'll be creating.  Well (and I'm sure there's a keyboard shortcut for this), just right-click the type and choose to create it!:

And this creates a new .cs file and class for you:

Now go back and run the test, and it'll turn green.  Now you're god to go again and to continue on your merry way and create more tests.

Finally there's a nice window to show you all the tests in your solution and get to them quickly and start running whichever tests you want:

This is a small taste of what the ReSharper test runner can provide you.  It's just very usable and one part of functionality ReSharper can give you outside of pure intellisense, code complete, and the array of other stuff it provides out of the box.

Try, it, give it whirl sometime and please, please be patient and allow yourself to get used to ReSharper.  Don't expect to use all of what it offers either, over time you'll find things you like about it as you use it.  The point isn't to use everything, that's impossible.  I think if you give ReSharper a chance, you're going to really benefit from it in the long run.

Rhino Mocks...

Is "Officially" a Dead/Retired Project 

Shortest blog post ever...but felt it was important enough to pass on in case you are thinking about adopting Rhino Mocks for your next mocking framework.

A Journey to TDD - Part 1

Well it's time to start up my blog again.  No need for a long intro here.  Lets just dive into the good stuff.

I've had a lot of things on my mind lately on what to blog about.  

Some immediate thoughts that came to mind:

• Webstorm IDE
• JavaScript Frameworks
• IoC / Dependency Injection

However one of the most important that I think every developer in our trade should be doing is Test Driven Development.  And now's about the time I start pushing myself to do it.  No more procrastination or excuses, TDD is no longer a nice-to-have or "we'll get there".  It's essential to high quality Software Development.  Some may disagree and you are entitled to your opinion.  I am not here to debate TDD.  I know what it can do, its power, and how it can make our lives easier as a Software Engineer having only done a little bit of it, but not enough to get a good taste of it yet.

You see I am tired of seeing methods that are 5+ lines long.  I'm tired of seeing only Unit Tests done after code, which are really just Integration tests;  sorry to break it to you folks, but these are not true unit tests and there's a major difference here.  

First, please watch the following video before you continue on.

I've seen integration tests that were complete messes because:

• Developers often admit they have no clue what to unit test; they keep asking themselves what should we test for x,y,z methods????  
• well when you practice TDD, you write tests based on use cases or user stories.  You don't have to in the end "wonder" what should have code coverage and what specifically should I be testing
• The tests were testing more than one thing per test  
• well this is a blatant violation of TDD
• A unit test should test and assert ONE thing...not 2, not 3, and God forsake you test more (I won't even go there)
• and of course you will have MANY very small tests but that is the point! because when tests fail, they fail at the lowest level in code, thus pointing you to the root cause quickly because your tests were small  

What TDD brings to the table:

• Clean, SOLID, Readable, already tested, and extensible code is a side-effect of TDD
• Most devs who do TDD follow SOLID principals
• Allows you to immediately find cause of failure at the lowest level of code
• When used in conjunction with Continuous Integration, you get instant feedback across your entire code base frequently and since it's automated it becomes engraned in your development team's culture and way of getting things done
• Promotes much more communication among fellow developers and in many cases the business
• Encourages the creation of simpler, more focused libraries and APIs
• Promotes LEAN development, meaning the test you write via TDD are directly related to business requirements from use cases.  So you are only writing the very minimal code you need to meet that use case.  Code waste is drastically reduced and time savings are exponential because of it for the entire team and the business

You see when you are Test Driven, SOLID and clean code are an end product and occur naturally as a result of doing TDD.  When you do TDD, it makes you constantly think and reassess HOW you are coding what you code. In other words, clean code, SOLID, and readable code is not an afterthought.  It's core to what you do while you write your tests.

But of course, we know that TDD isn't easy to learn or to do perfectly the first time:

• Big learning curve up front
• yes you will slow down and invest time up front at first, but eventually whittles down to being routine not a huge deal later on
• but slowing down is not a bad thing
• Also that slowing down period is good.  It makes you think about the code you write.  You're forced to think about clean code, just by the nature of doing TDD.  When you test first, you have to think about what you really need at a bare minimum which leads to cleaner, more readable code
• It takes time to learn to write good tests
• but over time you become better; don't let that deter you or prevent you from writing them, just write them, even if they're not perfect
• Mocking is not easy at first, but is a necessity as part of unit tests

The cost in terms of time it takes to dedicate and stick with learning TDD is worth it to me.  I'd rather spend my time learning to write Test Driven Development, then to troubleshoot may methods that are many lines long, or classes that are ridiculously long (violating badly the SOLID principals), etc. all while continuously popping Advil all day long because sloppy code is giving me head spins.  I'd rather live a healthy life at work and at home which means cleaner code will be healthier for all.

Tipping Point:

You see I know there's a tipping point, where the "hard" part of TDD will eventually fade away after hard work of learning it, and you know what that means?  It means I'll be able to go home at 5pm each day to be with my family because why?  Because we write Test Driven code.  

TDD is one of the biggest steps a team can make to having a sane and enjoyable development shop where you find bugs early, not after QA finds them.   It means when the business asks me hey Dave, are you guys able to add this new feature quick?  I can say certainly but more than that, I know that the code we create for that feature will be solid, reliable, and already tested.  There is no guess to what you should test because we are not writing integration tests (unit tests after the fact), your tests drove the creation of your real code so there's nothing to wonder about which frees up all that time other teams are aimlessly trying to figure out what integration tests to write and end up writing a ton of tests that are frankly useless because they aren't doing TDD.

Some Resources:

Before I dive into the next part of my journey which is to start doing TDD, I wanted to list some very good resources I've collected over time.  These are resources I've read, watched, etc. and are high quality in my opinion as it relates to the topic of Test Driven Development:

Roy Osherove's website and his awesome book The Art of Unit Testing

             Other good vids from Roy

•           Understanding Test Driven Development
•    Roy Osherove - Mocks & Stubs sneak Peak
•            Understanding Mock Objects
•            Unit Testing Best Practices - Roy Osherove - Art of Unit Testing
•    Naming standards for unit tests - Roy Osherove
•    Unit Testing Best Practices
•    Bouvet Developer Meetup - Roy Osherove on Unit Testing Good Practices
•    Unit Testing Worst Practices
•    Readable, Maintainable, Trustworthy Unit Tests
•    Pairing with TDD Videos
•    TDD Pairing Session 1 with Raymond Lim and Roy Osherove
•    TDD and Pairing Session 2c: Go Game Engine with Raymond Lim

Uncle Bob Martin's Posts and Talks

• Advanced Concepts in TDD 

(in this talks about a lot of basics too, not really all advanced so view this as an intro as well.  Uncle bob codes and shows you how to do TDD in this one, it's an excellent video to watch when first starting out with TDD)

Other good links

• The Downfall of Agile Hitler
• Test-driven development: Write better code in less time
• An Introduction to Test Driven Devlopment in .NET
• Automated Testing & Inversion of Control

JavaScript and TDD

• Test Driving JavaScript
• 3JavaScript Testing With Jasmine - The Basics
• Unit Testing in JavaScript via Jasmine
•  Jasmine: BDD Style JavaScript Testing Hello World
• TDD in JS: No Excuses (includes jasmine test framework)
• FizzBuzz in JavaScript (using TDD and Jasmine)

I'm not going to go into all the semantics at this point of TDD such as write your tests to fail, then refactor to make them pass, yada yada.  That's for you to research.  A good start are the resources above.

And Finally, as we all should, I have a lot of pride as a Software Craftsman. 

Pride means the following to me:

• The code I write has to be read and maintained by other developers;  the least I can do for my fellow teammates is to do my best to write clean code 
• don't you hate working with sloppy code?  of course you do, everyone does
• Just like Mechanical Engineers, Industrial Engineers, etc., we are Software Engineers first and foremost   

• We are professionals, not code monkeys, not slaves.  We are paid to write working software but IMO software that stands the test of time and does not kill you to maintain and extend (AKA SLOP)

• and I highly agree with Uncle Bob here that Speed Kills

• What I have produced for the business has an immediate impact and immediate results not only now but I want to feel like I have  tried my best to make sure it's clean, readable, reusable, and extensible as possible so that it may be useful and continue to have an impact in the future
• I can have confidence in what I code and the business can have confidence in its products
• I continue to learn good coding habits as a side-effect of TDD
• It means I take my job seriously as a Software Craftsman

The purpose of this journey is to share what I learn as I transition to making TDD a first class citizen in my work habits as a Software Engineer developing code.  Part 2 will transition into actually doing some TDD...

Until next time, I highly urge you to check out the resources I've listed above.  Some are surprisingly entertaining as you will find out :).