Installing & Using Chocolatey Package Manager for Windows

I'm very used to using tools like npm to install node modules in an OS X bash environment.  Or tools like Homebrew + Cask as well, I use both ways.

Windows sorta has a Homebrew'ish like that called Chocolatey which is a Nuget based package manager via command-line that attempts to mimic something like the popular Homebrew in OS X.

With package managers you can do all sorts of cool things such as install stuff in 2 seconds rather than go out to the net for executables.  For example one can do this to install a bunch of common programs you might use in your development environment:

choco install google-chrome-x64

choco install firefox

choco install git.install

choco install atom

choco install 7zip

choco install ccleaner

choco install node.js

choco install filezilla

choco install fiddler

choco install virtualbox

choco install pdfcreator

choco install windirstat

choco install itunes

and because you're using a package manager and its commands, that means you can automate creating your development environment too by creating a chocolately script or HomeBrew script or whatever.  

Imagine creating a script that you could run on a fresh install of windows that does a bunch of chocolatey commands (or equiv of Homebrew in OS X) to install and setup your entire local dev environment.  Sure would save a hell of a lot of time.  Especially if you haven't imaged your laptop the last time you went through the pain of setting up our dev environment manually.  When i say manually, meaning do the typical go to the web, go to FireFox, Google, and other sites to manually click all over and download and then run the exe, stupid wizards, all that.  You can bypass a lot of that hassle and save time by creating scripts along with using Chocolatey or HomeBrew and automate most of the things you use as a developer.

I use Powershell for all that I do.  So I'll use PowerShell to install Chocolatey.  You can also just use the command prompt but why not just use PowerShell is my argument.

Here is how to install it

    There are a couple little pain points that you need to be aware of if you haven't used PowerShell and such while trying to install Chocolatey that you'll come across.

1. First, make sure you elevate privileges with PowerShell to allow the Chocolately script to be run on your comptuer

  Run the command Set-ExecutionPolicy RemoteSigned

    2.  Install Chocolatey
         Run the command: 
           ex ((new-objec net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

3.   Start using it

      Here I'm installing Git for Windows with a simple Chocolatey command:

So simple.  Now it's installed.  Note that there are many Git packages up on the Chocolatey website.  This one installs Git and then you can start making Git commands right from PowerShell thereafter:

This is not installing something like Mysis Git Bash prompt.  If you want something like MysisGit, if there isn't a package that does that for you in the Chocolatey Packages directory listing then you'd have to go manually install it yourself.

You can also quickly install stuff like Chrome which will do everything you expect..pulls down the Chrome executable runs it and installs it for you without you needing to do a thing.  All you have to do is type choco install google-chrome-x64

This just scratches the surface.  Windows 10 is coming out with their own built-in Package Manager finally.  We'll see if it's any good.

Using ReSharper to remove Code Smells and Keep Code Cleaner

I promote ReSharper always as a necessary tool that I feel all developers should definitely be using.  In fact there are teams I've been on that require it as they've decided that the tool is so useful that everyone should be on board and using it because it helps so much that it became a requirement to use it literally.  And on those teams developers didn't debate using it, they were already using it or if they weren't they were all for it because they saw how it can literally help the team to be more efficient in so many ways.

One of the big reasons to try and make it a standard on your team is about is keeping code clean.  Some people don't think they have any use for a tool like ReSharper.  They're "proud of manually coding everything without much assistance from intellisense".  Well that's just ignorant.  And most likely those kind of developers are producing code smells for the rest of the team and they don't even know it or causing themself extra pains that they weren't even aware were walls/pains in the first place on a day-to-day basis!

And remember your code is everyone's code.  The code base belongs to the entire team, not just you.  So if you think it's ridiculous to keep even the smallest lines of code clean and it's below you, you might consider another profession.  Do you think accountants allow messes?  Doctors?  The answer is no and it should be no different in our profession as Software Engineers or "Craftsmen".  What you do affects everyone in your development team so you need to view the code YOU write as such at all times and be thinking about how it might be reusable, cleaner, etc. for everyone else who has to work with it in the future.

Turning back to ReSharper.  It's such a gem in that it clearly points out unnecessarily code in every class and every line of code in that class.

There's no reason if you have ReSharper installed that you aren't by habit removing unnecessary code as you come across it, which is part of the boyscout rule, keeping the code campground clean.  As you know the boyscout rule that so many great teams abide by is that every time you check in code, it should be a little better than what it was before you check it in.  Robert Martin's Clean Code book emphasizes the boyscount rule.

When you are in a class and you have ReSharper installed, this stuff just screams out at you.  And for me it's just a habit to remove it.  It feels gross to have it in here...and you should feel the same way.  It takes up no more time doing this;  It does not slow me down as it's just a few seconds to remove this stuff as you go and as you see it elsewhere in an entire class.

Look at these examples where ReSharper has pointed out/grey out unnecessary code (I pointed it out with yellow here):

unused usings

unecessary "this." where there is no object type conflicts whatsoever

unecessary Fully Qualified Types where you should have added a using statement

unnecessary explicit conversions:

unnecessary chatter:

unnecessary default assignments at times

Would the examples above give you "code itch" if you knew about them?  It's very much code smell, and it really should make you itch if you truly care about keeping your code base clean.

Why should we removed this stuff? for READABILITY, simple as that.  And having more readable code leads to easier maintenance for all.  Don't be lazy, get rid of it NOW while you are working in that class before you check it in.  ReSharper makes it stupid easy and quick do do this, and It's part of being a professional Software Engineer to keep this clean.

One of the things I do just by good habit right off the bat is when I make a new class in C#, I immediately remove the default usings that are generated at the top as initially they are unused anyway.  half the time you won't end up need a lot of them once you are done with the class anyway.  ReSharper will simply hint and allow you to add using statements quickly and easily anyway when it detects you need them.  So start off with a nice clean template is what I highly suggest so that this stuff is removed initially to start with.

Now you may be thinking "hey I like to show things explicitly to make code more readable". You know what?  you're actually making it less readable.  For instance if you think you still need to do something like establishing a variable with default such as int someVariable = 0; and you know though in certain cases you don't need to explicitly show that you're setting it to zero.  Seriously, stop over thinking and just get rid of it.  It's like the same with commented out code, get rid of it, it's clutter.  99% of the time you'll never use that commented code again.

ReSharper's Marker Bar

Now another thing that people who have even used ReSharper for a while don't know about or notice which for me is an awesome feature is  the Marker Bar.

When you open a class, look to the right.  ReSharper outlines problems, hints, or suggestions in code making it very easy to see an overview of your class in terms of code quality and errors that exist:

And all you have to do to get to that line of code that is a problem is to click on that colored bar on the right.  

ReSharper shows different colored bars to the right to point out different things:

Don't you love that?  In fact there was a team I worked with who decided that a good standard for the team as part of cleaning up code would be to check this in every class you've made changes to BEFORE you check in the code.  

So get rid of unnecessary code or use the hints to make the code more compact, do it, then check it in.  You start to view your classes different with this feature too.  Because when you open classes, you start to look to the right automatically and it just becomes a habit to use this feature to see if you can clean something up before saving your code and checking it in.

This just touches the surface in how ReSharper can help a team keep code consistently clean and uniform.  There are many more features that I'd like to resurface later in a future blog post.

While most ReSharper users already know about this, there are plenty of developers who have never heard of a tool like ReSharper, refuse to use it, or don't understand some of its benefits.  So I like to resurface some of this stuff once-in-a-while hoping a newbie finds out about ReSharper and some great stuff they and their team are missing out on.

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.

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.