Saturday, October 31, 2015

November 2015 Speaking Engagements

Things are slow and busy for me in November. The few things I have, I'm really looking forward to.

Mon - Fri, November 16 - 20, 2015
Visual Studio Live!
Orlando, FL
Website
o DI Why? Getting a Grip on Dependency Injection
o Unit Testing Makes Me Faster: Convincing Your Boss, Your Co-Workers, and Yourself

I'm really looking forward to speaking at Visual Studio Live! this year. This is a conference that I used to attend and got lots of great information from. I'm really honored that I've been selected to share some of my experiences.

Dependency Injection and Unit Testing are both favorite topics of mine. These are things that took me a while to really learn but have become invaluable in my programming. I love helping people take a shorter road to understanding than I did. It will be a lot of fun.

Other Stuff
The first week in November, I'm headed to Redmond, WA for the Microsoft MVP Summit. This is always a great time - lots of content (most of which is under NDA so I can't talk about it), lots of time with old friends, and lots of time to meet new friends. It should be a great week.

Here's my report of last year's summit: Microsoft MVP Summit -- A Great Opportunity.

Upcoming Events
I found out this week that I've been selected to speak at NDC London 2016 in January. This is an amazing opportunity for me, and I'm looking forward to the trip. (I've just been notified of the selection, but I'm not sure which of my proposals was chosen.)

Also in January, I'll be speaking at CodeMash in Sandusky, OH. I've heard lots of great things about CodeMash, and I'm excited about experiencing it for myself.

Past Events
I had a great time at Silicon Valley Code Camp in October. This is always a great event, and I had a lot of fun presenting. I brought my banjo with me, and played it before my presentations. You can see how I've been progressing here: You Aren't Instantly Awesome, But You Can Get Better with Practice.


One great thing is that I had the opportunity to talk about Design Patterns on the big stage.


The good news for you is that this presentation was recorded, and you can watch it on YouTube: Learn the Lingo: Design Patterns by Jeremy Clark at Silicon Valley Code Camp.

As a reminder, I'm available to come to your conference, user group or developer event. Just drop me a note, and we'll see what we can work out.

Happy Coding!

Monday, October 19, 2015

New Video: Git Basics for Visual Studio Developers

Git can be a bit of a stumbling block for Visual Studio developers. That's because we're generally used to centralized source control systems like TFS. In addition, there seems to be an emphasis on using command line tools to interact with Git repositories. Because of these differences, we often put off learning Git because it seems like it will be a lot of effort.

But in reality, with just a few key commands and the tools built in to Visual Studio, we can get started with Git very quickly. And that's what I show in my latest video -- along with some GitHub hints as well.

I've been using Git for less than a year, and I'm completely sold. I love having the complete repository on my machine. That means I get full history, branching, and roll-back capabilities without being connected to a central server. I'm not an expert, but I'll help you get started.

Watch it on YouTube: Git Basics for Visual Studio Developers

Or here:


For more resources on getting started with Git, check no further than here: Getting Started with Git.

Happy Coding!

Wednesday, October 14, 2015

You Aren't Instantly Awesome, But You Can Get Better with Practice

Back in June, we looked at having realistic expectations when we try something new: You Aren't Instantly Awesome, and That's Okay. To get this point across, I play my banjo at my speaking events (when possible).

When we walk up to something new, we aren't immediate proficient. There is a learning process. And if we spend time with it, we will keep getting better.

It's time to see if I've been getting better at banjo. Here are a few recordings that I've done at some speaking events.

June 29, 2015
Here's the recording that I posted earlier from So Cal Code Camp in San Diego, CA:


August 27, 2015
About 2 months later, I was at South Bay .NET in Mountain View, CA. This is when I was just learning to play with finger picks:




September 24, 2015
A month later, I was at the NWVDNUG and SEVDNUG user groups in the Phoenix, AZ area:


Here's a photo of me playing the night before at Northwest Valley .NET User Group:



October 3, 2015
And a few weeks ago, I was at Silicon Valley Code Camp in San Jose, CA:


On Sunday, I was on the big stage, and they recorded my pre-show:


If you're curious about the "Duck Typing" picture that's mentioned at the end of the video, here it is:


The rest of the presentation is available to watch here: Silicon Valley Code Camp - Learn the Lingo: Design Patterns.

Keep Practicing, Keep Improving
I'm getting better one step at a time. Every so often, we need to take a look back to review our progress. This is how we can see if we're making improvement. And if we're not improving, then we can re-evaluate what we're doing to see how we can get better.

Learning is a process. And it's a process that never ends. Keep learning, keep practing, and keep improving.

Happy Coding!

Wednesday, October 7, 2015

Microsoft MVP Award 2015

I was honored with the Microsoft MVP award again this year. As you can see from the picture, this is the 4th time I've been awarded.

The Microsoft MVP award is a way that Microsoft recognizes people who contribute to the community -- whether through answering forum questions, speaking at developer events, writing technical blogs, producing videos, running events, contributing to open source projects, or many other ways.

My passion is making developers better. One of my primary outlets for that is speaking. So far this year, I've given 44 presentations at 27 events. If you haven't figured it out yet, I enjoy this quite a bit.

In addition, I've produced 10 videos for my YouTube channel on Clean Code, Lambda Expressions & LINQ, and Task & Await. I've been sharing lots of stuff on my blog as well -- 73 articles so far this year, and hopefully mostly useful content. And I've got some more cool things planned before the end of the year.

I'm doing what I'm doing because I love to do it. It's a great bonus to get recognized by Microsoft for my contributions. This also gives me the chance to associate closely with other Microsoft MVPs -- a great community of smart and friendly people who share their expertise with other people.

Share what you know with other developers. This is how we all learn, and how we grow stronger as a community.

Happy Coding!

Tuesday, October 6, 2015

Getting NUnit Test Parameters From a File (or Other Source)

NUnit has *a lot* of options. One of the options that I like is the ability to easily parameterize a test by using attributes. For an example of this, see Parameterized Tests with NUnit. During one of my recent presentations on testing, someone asked:
Is there was a way to get test parameters from a file or a database?
The answer is Yes!

Let's take a look at some of the different options that we have for providing test parameters for NUnit to use.

The Unit Under Test
Before looking at the tests, let's take a look at the method that we're testing. This code is taken from "Unit Testing Makes Me Faster", and you can download the code here: Session - Unit Testing Makes Me Faster.

Here's the method -- PassesLuhnCheck:


This method runs the Luhn algorithm against a potential credit card number. This doesn't tell us whether a credit card number is valid, but it tells us whether the card has the potential to be valid.

For example, let's think about validating a phone number. If it has 10 digits, then it has the potential to be a US phone number. But if it has "555" in the middle (like "714-555-1212"), then we know that it is not a valid number, since "555" is a fake exchange that is used in movies and television.

The Luhn algorithm does something similar with credit cards (only with arithmetic on the digits themselves). This is mainly to catch if someone transposes 2 digits when entering a card number.

You'll notice that I don't show the body of the method here. That's because it isn't important for what we're doing. We're doing some black box testing: valid numbers should return "true", invalid numbers should return "false".

So, let's look at some tests.

Parameters in Attributes
The first way to get parameters into our tests is by using attributes on the test methods themselves. This is what we saw in the previous article about parameterized tests. Here's our test for numbers that should pass the Luhn check.


This has a number of "TestCase" attributes. The parameter in the attribute is passed as a parameter to the test method -- the "testNumber". Then the test just runs the "PassesLuhnCheck" method and verifies that it returns true.

BTW, don't bother trying to buy things with these numbers on Amazon; these are test numbers provided by the credit card industry. They pass the Luhn check, but they are not valid accounts.

There is a similar test for invalid numbers:


And here are the results of our tests:


Notice that we get a test result for each of our test cases. By looking at the parameters, we can tell which number was used with each test. This is one of the cool things about how NUnit handles parameterized testing.

But we have some other options as well.

Test Parameters in Code
Instead of putting the test parameters in attributes, we can also create the parameters in code. To do this, we just need to create an object array with the parameters that we want to use. In our case, we only have 1 test parameter, so we can use a string array. Here's what that code looks like:


Here we have our same test numbers, but we've put them into a static string array. Then our test is attributed with "TestCaseSource" and we tell it what object to use for the parameters.

We can do something similar for our invalid numbers:


When we run the tests, we get the same results.


So far so good. But what other options do we have?

Test Parameters From a File
It would be really great if we could get our parameters out of a file (or database). For that, we'll need to parse a file. Here's what our test file looks like:


This is the "NumbersToTest.txt" file. The format isn't ideal, but it's not very difficult to parse in code, either. Instead of using a static string array, we'll use a static method that returns a string array. Here's our code:


Let's walk through the "MorePassingNumbers" method. Here we have a path to our test file. I just hard-coded this to make things easier. Then we read all the lines in the file. We skip the first line since that has the "VALID NUMBERS" label. Then we keep reading until we get to an empty line.

The end result is that we have a string array of our valid numbers. Then we just have to update our "TestCaseSource" attribute parameter to use "MorePassingNumbers".

We can do something similar with the invalid numbers:


This code is similar. The difference is that we skip everything in the file that comes before the "INVALID NUMBERS" label. Then we skip one more line (the label). Then we read to the end of the file.

After updating the "TestCaseSource" attribute, we see that we get similar results to what we had above. But this time, we're reading from a file:


Now that we're running code to get our parameters, we can get our parameters from wherever we want. Instead of opening a text file, we could make a database call -- although we need to be aware that we want to keep our dependencies light so that our tests have a good chance of running successfully.

We have some other options as well.

Using TestCaseData
We'll look at one more option. This gets interesting if we have our test parameters and expected results stored together. Instead of having 2 separate tests, we can have one. Then in our parameters, we also supply the expected result of the test.

For this, we'll use a class from NUnit called "TestCaseData". We need to create a public static class that has a public static property. This property should return an IEnumerable that consists of TestCaseData objects.

Here's an example of that:


If you're not familiar with the "yield return" statement, this just lets us create our own IEnumerable really easily. In this case, we're just using hard-coded data.

Each time we ask for the next item of our IEnumerable, it will return whatever is at the next "yield" statement.

Now let's look at the TestCaseData object. First we construct the object (using "new TestCaseData"), and the parameter is the parameter that we want to use for our test. If we had multiple test parameters, then we would pass them into the constructor here.

Then we use a fluent syntax to denote that we expect a particular return value based on this TestCaseData. So we can see that each of our test cases will expect a true or false value depending on the number.

The test that uses this data looks a bit different from the other tests we've looked at:


First notice the attribute. We use the TestCaseSource attribute. Then for the parameter we use "typeof" with the name of our class -- in this case "CreditCardTestCases". The next parameter is the name of the property that we want from that class -- "TestCases".

The test itself has a parameter (testNumber) like before, but the rest of the method is quite a bit different. We return a "bool" value here (instead of "void" like our other tests). And then the body of the method just runs our method under test and returns the result.

NUnit will look at the TestCaseData and pass in the parameter. Then it looks at the result value and makes sure that it matches the "Returns" part of the TestCaseData.

We only have 1 test now that handles both the valid and invalid numbers. And we get the expected results in our test explorer:


I'm not a big fan of having a single test because when I look at the test results, I can't tell whether I'm testing a valid number or an invalid number. When a test fails, I want to look at the test name (and parameter) to figure out what failed. In this case, we'd have to drill into the test results to see the expected result (true or false).

Getting Data From a File
As you can imagine, we can use this same technique to get data from a file or database. Let's see how we can get our test parameters and results from our text file:


This is a bit more complex that I'd like due to the nature of our text file. We get 2 different collections from the file -- one for the valid numbers and one for the invalid numbers. This uses that same parsing that we saw above (and it's not very efficient since we read the file 2 times). We could probably spend a bit of time to optimize this.

Then we have 2 "foreach" loops. Each of these has a "yield return" which will return the appropriate "TestCaseData" object. And the reason we have 2 loops is that we do not have the expected result in our file, so we need to hard-code that here.

Another option is to change the format of the text file so that it includes both the number and the expected result. This would be pretty easy to do, but for this simple example, I just wanted to keep the current file format. You can use your imagination for parsing a different file format (or even querying a database).

To use this in the test, we just need to update the property name in our attribute:


This now points to the "TestCasesFromFile" property that we just looked at. And as you can imagine, we still get the expected results from our test:


Again, I don't really like the idea of having the combined test, but I've talked to several people who do like to format their tests this way. If it works in your environment, and the members of your team understand it, then there's no reason to change it.

Wrap Up
NUnit is a very flexible testing framework. We've seen several ways to get parameters into our test, and we haven't even seen all of the options for that. For more information, be sure to check out the NUnit documentation: NUnit - TestCaseSource Attribute.

I'm always looking at what features are available in the tools that I use. I may not use all of them (in fact, I probably won't use all of them), but it's great to know that there's an easy way to solve a particular problem if it pops up in my code.

We should keep learning about the tools we use and the tools that are available to us. This will save us lots of heartache and will keep us from building things ourselves. It's always great to find that particular feature that is just what we need for a problem.

Happy Coding!

Thursday, October 1, 2015

October 2015 Speaking Engagements

This weekend, I'll be at Silicon Valley Code Camp in San Jose, CA. Nothing else planned for the rest of October, but you never know what will pop up.

Saturday & Sunday, October 3 & 4, 2015
Silicon Valley Code Camp
San Jose, CA
Website
Topics:
o DI Why? Getting a Grip on Dependency Injection
o Learn the Lingo: Design Patterns

This will be my 4th trip up to the Silicon Valley Code Camp. I'm looking forward to seeing some old friends and meeting a lot of new people. There is always a huge spread of technologies, so regardless of what language or stack you work on, you'll find something relevant to you. In addition, it's a great place to explore technologies you don't normally work with.

I'll be giving 2 talks: Dependency Injection and Design Patterns. These are 2 topics that I really love to share. Most people are introduced to them a bit backwards, and so they miss out on the great things that they offer. We'll take an easy run-up -- showing the basics in an approachable way. But we'll ramp things up to see the real power offered.

A Look Back
I had a great time speaking in September. I visited 2 user groups in the Phoenix area (North West Valley .NET User Group and South West Valley .NET User Group) and had a lot of fun. It was great to spend time with my friends in the area and also get to know some folks a bit better.

In addition, I spoke at a corporate event in Irvine, CA, and had a chance to share about Clean Code, Defensive Coding, and Dependency Injection.

Here's a few pictures that people were nice enough to take and tweet out during my stay in the Phoenix area:

Jeremy breaks out the banjo at NWVDNUG
NWVDNUG in Glendale, AZ - Jeremy talks about Task, Await, and Asynchronous Programming
SEVDNUG in Chandler, AZ - Jeremy typing frantically to show the coolness of Unit Testing
I also had a chance to give a quick sales pitch for Becoming a Social Developer:

SEVDNUG - Jeremy talks about Becoming a Social Developer
When you're at developer events, whether a user group, code camp, or conference, take advantage of the time to talk to the developers around you. We all get better by sharing our experiences. If you haven't checked out the website yet, be sure to do it now: www.becomingasocialdeveloper.com. Also be sure to share your ideas on how to spread the word to other developers and encourage them to join in.

A Look Ahead
I've got a few exciting things coming up after October. In November, I'm speaking at Visual Studio Live in Orlando, FL. The folks at SEVDNUG got a preview of one of my talks ("Unit Testing Makes Me Faster: Convincing Your Boss, Your Co-Workers, and Yourself"), and I want to give a big thanks to Barry Stahl, J. Michael Palermo, and Justin James for hanging around to give me feedback. The fine-tuning will make the talk even more awesome.

And this week, I found out that I've been accepted as a speaker at CodeMash in January. I've heard really great things about that event, and I'm looking forward to going out to Ohio and meeting a whole new slew of people.

I hope to see you at an event in the future. And if you want me to come to your event, just drop me a note, and we'll see what we can work out.

Happy Coding!