Tag: Testing

ProjectXyz: Why I Started a Side Project (Part 1)

ProjectXyz

Alright, I’ll admit it… Even for a placeholder name on a side project it’s pretty terrible, right? Well, my apologies. So, if you made it to this post you might be wondering what ProjectXyz is and why I started it up. From a high level, I started working on ProjectXyz so that I could have a hobby programming project to tinker with and I figured I’d blog about my adventures in bringing it all together. I plan on making this a mini-series documenting some of the things I’m learning or experimenting with, so this will serve as the intro to the series.

Before we get too far, here’s the link to the GitHub site: https://github.com/ncosentino/ProjectXyz

Why Have a Side Project?

Here’s the main thing I want to talk about in part 1 of this series: Why should you have a side project?

From my experiences in high school and university, I found that having a side project that I could code in was probably the best way that I could continue to learn. It’s a low stress activity that encourages you to be highly creative. You can involve as many other people as you want, or work on it completely solo so that you can minimize external stress and maximize your own creativity. It’s your project, so you have the freedom to do what you want.

I leveraged various small side projects to learn things like how sockets work or how I’d try and structure a multi-tier application. I was able to work on refactoring large amounts of code and learn how to use source control to my advantage. Was there a design pattern I wanted to learn about implementing? Great! Then I could try and find a way to incorporate it into my projects. The goal was always about trying to implement new things and not about cutting corners to try and deliver something to an end user.

Once I started work full-time, I gave up on my programming side projects. I started up this blog which has been fun and I try to take on as much work for my career as I can because I actually enjoy my job… But I stopped coding my own hobby projects. I’ve found that I’m missing out on two major things as a result of that:

  • The ability to experiment with patterns, technologies, and frameworks
  • The ability to get really creative and try out completely new things

Work has been a great opportunity to learn, but it’s learning out of necessity. Myself or my team will hit blocks and we have to work together to try and overcome them. It doesn’t give me the opportunity to go completely into left field to try something new out. Having a side project gives me a bit of freedom to try and learn all sorts of really neat things.

So… Why ProjectXyz?

Okay, well, if you mean why the name… Then I don’t have a great answer. I wanted to start coding but I didn’t want to waste time thinking about a name. I’ll think of something better later, I promise.

Otherwise, you might be wondering why I decided to build ProjectXyz to be what it is (or, what it will be). ProjectXyz is the back end (i.e. not the pretty graphical part) for a role playing game, and I’ve played around with this kind of thing before. I like playing games like this, and I’ve had a lot of fun trying to create a game like this in the past. As a result, I can really focus on what I’m building and not trying to figure out what to build. I’m not pouring energy into wondering “how do I solve this great big popular problem with this piece of software?”, but instead I can just get as creative as I’d like. It’s not about “What does the customer want?”, but instead, I can ask “What do I want to make?”.

The things I’m looking to try out with ProjectXyz (to start with, at least) are:

  • More LINQ usage
  • Coding by interfaces
  • API design
  • Dependency injection and IoC
  • TDD and coded test designs
  • Moq for mocking my classes
  • … GitHub! To make some publicly visible code.

As I work through ProjectXyz, I’ll write more posts on the various things I’m learning as I go! Check out the GitHub page and drop some comments!

https://github.com/ncosentino/ProjectXyz
(The second post in this series is here)


Refactoring For Interfaces: An Adventure From The Trenches

puzzle

Refactoring: Some Background

If you’re a seasoned programmer you know all about refactoring. If you’re relatively new to programming, you probably have heard of refactoring but don’t have that much experience actually doing it. After all, it’s easier to just rewrite things from scratch instead of trying to make a huge design change part way through, right? In any mature software project, it’s often the case where you’ll get to a point where your code base in its current state cannot properly sustain large changes going forward. It’s not really anyone’s fault–it’s totally natural. It’s impossible to plan absolutely everything that comes up, so it’s probable that at some point at least part of your software project will face refactoring.

In my real life example, I was tasked with refactoring a software project that has a single owner. I’m close with the owner and they’re a very technical person, but they’re also not a programmer. Because I’m not physically near the owner (and I have a full-time job, among other things I’m doing) it’s often difficult to debug any problems that come up. The owner can’t simply open an editor and get down to the code to fix things up.

So there was an obvious solution which I avoided in the first place… Unit tests. Duh. I need unit tests. So that’s an easy solution right? I’ll bust out my favourite testing framework (I’m a fan of xUnit) and start getting some solid code coverage. Well… in an ideal world, like every programming article is ever written, this would have been the case. But that wasn’t the case. My software project does a lot of direct HTTP/FTP requests and interacts with particular hardware on the machine. How awesome is writing a unit test that contacts an HTTP server? Not very awesome.

What was I to do? I need to be able to write unit tests so that I can validate my software before putting it in my customer’s hands, but I can’t test it with unit tests because I don’t have the hardware!

Refactoring for Interfaces

Okay, so the first step in my master plan is to refactor for interfaces. What do I mean by that? Well, I have a lot of code that will call out and make HTTP requests and it has a specific dependency on System.Net.WebRequest. The same thing holds true for my FTP requests I want to make. Because I have that dependency within my classes, it means I have no choice but to call out to the network and go do these things.

I could design it a different way though. What if I abstracted the web requests away so that I didn’t actually have to call that class directly? What if I could have a reference to some instance that met some API that would just do that stuff for me? I mean, my class knows all about it’s on particular job, but it truthfully doesn’t know the first thing about calling out to the Internet to go post some HTTP requests. This means if someone else is responsible for providing me with a mechanism for giving me the ability to post HTTP requests, this other entity could also fool me and not actually send out HTTP requests at all! That sounds like exactly what my test framework would want to do.

My first step was to look at the properties and methods I was using on the WebRequest class. What was shared between the HTTP and FTP requests that I was creating? The few things I had to consider were:

  • Some sort of Send() method to actually send the request
  • A URI to identify where the request is being sent
  • A timeout property

I then created an interface for a web request that had these properties/methods accessible and created some wrapper classes that implemented this interface but encapsulated the functionality of the underlying web requests. The next step was creating a class and interface for a “factory” that could create these requests. This is because my code that needs to make HTTP/FTP requests only knows it needs to make those requests–It doesn’t have any knowledge on how to actually create one.

With my interfaces for my requests and my factory that creates them, I was able to move onto the next step.

Create Mocks for the Interfaces

Now that I had my classes leveraging interfaces instead of concrete classes internally, I could mock the inner-workings of my classes. This would provide two major benefits:

  • I could create tests that wouldn’t have to actually go out to the Internet/network.
  • I could create instrumented mocks that would let me test whether certain web requests were being made.

I started off my writing up some unit tests. I tried to get as much code coverage as I could by doing simple tests (i.e. create an object, check default values, call a method and check a result, etc…). Once I had exhausted a lot of the simple stuff, I targeted the other areas that I wasn’t hitting. I mean, how was my coded test supposed to test my method that does an HTTP request and an FTP of a file under the hood? Mocks.

So this is where you probably draw the line between your integration tests or unit tests and get all pedantic about it. But I don’t care how you want to separate it: I need coded tests that cover a section of my class so that I can ensure it behaves as I expect. But if I’m mocking my dependencies, how do I know my class is actually doing what I expect?

Instrument your mocks! This was totally cool for me to play around with for the first time. I had to create dummy FTP/HTTP requests that met the interface my class under test expected. Pretty easy. But I could actually assert what requests my class under test was actually trying to send out! This meant that if my method was supposed to try and hit a certain URL, I could assert that easily by instrumenting my mocked instance to check just that. Was it supposed to FTP a certain set of bytes? No problem. Use my mocked instance to assert those bytes are actually the ones my class under test is trying to send.

Wrap Up

This was just a general post, and I didn’t put up any code to go along with it. Sorry. I really just wanted to cover my experience with refactoring, interfaces, mocking, and code coverage because it was a great learning for me.

To recap on what I said in this post:

  • Identify the parts you want to mock. These are the things your class or method probably isn’t responsible for creating directly. Going out to the network? Accessing the disk? Accessing the environment your test is running under? Creating complex concrete classes because they hook into some other system for you? Great candidates for this.
  • Create interfaces by looking at the API you’re accessing. You know what classes you want to mock, so look how you’re using the API. If you need to access a few properties and methods, then make that part of your interface. If you see commonality between a few similar things, you might be able to create a single interface to handle all of the scenarios.
  • Inject factories that can create instances for you. These factories know how to create the concrete classes that meet your interfaces. In a real situation, they can create the classes you expect. In a test environment, they can create your mocks.
  • Write coded tests with your mocks! The last part is the most fun. You can finally inject some mocked classes into your classes/methods under test and then instrument them to ensure your code under test is accessing them in the way you expect. Run some code coverage tools after to prove you’re doing a good job.

I hope my experiences down this path are able to help you out!


  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress