Category: Testing

My todo list for work in 2016

Its 2016 and I like to make a list of things I wanna look into and put into place at work so here is a list of things I am aiming to do which also includes at my job in 2016:-

  • A blog post each week, last year I only managed 11 blog posts and that’s poor, so more blog posts will come in 2016.
  • Lightning Talks, we have started doing these at work and this year I plan to do a few of them if given the chance, I’m doing one on the 6th of January on as Developers Top 10 Best Practices which I will share about once I have done my talk.
  • Test 3rd party end points, have a dashboard page which tells us what is up and what is down, going to try to use the Chrome add-on called Postman and use collections within Postman to do this.
  • Database Deployments, currently we manually script everything and then get the dba to run the scripts in manually, we need to script the database and put it into Source control each release as a starting point, I’m looking forward to this as it well help aid with our deployments and speed them up. Hoping to get the RedGate Sql Toolbelt into the company so we can use this to help us achieve this.
  • Red/Green deployments, we currently deploy at weekends and this can and should change so that we aren’t spending time at weekends doing releases which take quite a lot of time, we can automate them more and this year I plan to fix that.
  • More Testing, we are closing in on unit testing our PowerShell scripts, this will be another nice addition to the number of different areas which we are currently testing which is great.
  • Code Reviews, need to figure out a way that keeps everyone from being bored, brings benefit to the team and keeps us developers on our toes going forward.
  • Continuous Improvement, test more, more in-depth code reviews, automate more, release finished work, tackle the back log each sprint.

That’s it for now, I will add to this lost throughout the year as we go, i will keep an eye on this post and how we get on and blog about each one individually, hopefully I’ll get the chance to work on some if not all of these this year.

Feel free to follow me on twitter at @gsuttie



Code coverage results for your JavaScript

I wanted to find out if there were any tools that can display code coverage results for JavaScript code (without the need for Java on the server or having to use Node), I experimented with a few different frameworks, test runners and what not and have spent a couple of hours looking in to this, in the end I opted for the following:-

jasmine_logo At work we currently use Jasmine which is a behaviour-driven development framework for testing JavaScript code along with PhantomJS which we use to run the tests using a specrunner (there are several ways to do it but this works for now)

I have installed the Visual Studio Extension called Chutzpah which is a JavaScript Test Runner which gives you a few nice things such as integration with TeamCity and the ability to right-click and then select Run Tests similarly to unit testing your C# code with your favourite unit testing framework.

chutzpah

Ok so back to code coverage for our JavaScript code – Matthew the guy who created Chutzpah is working on integrating code coverage into the next release so in the mean time here is how you get it to work – enter one further library called Blanket.js – Blanket.js is used to give us the code coverage results and currently supports Qunit, Mocha and Jasmine. An adapter API exists for supporting other test runners.

At this point you might be thinking its a fair amount of work to get this going but I will simplify the steps required to get your JavaScript code outputting code coverage results.

  • Download Blanket.js and look for the file called blanket-jasmine.js, add this to your Scripts folder inside your web application. This file is blanket version that works with Jasmine.
  • Add the Nuget package jasmine.js jasminenuget
  • Add some JavaScript code as below for example this is code.js
  • [sourcecode language=”csharp”] var stringLib = {
    vowels: function (a) {
    count = 0;
    for (var i = 0; i < a.length; i++) {
    if ("aeiou".indexOf(a[i]) > -1) {
    count++;
    }
    }
    return count;
    }
    }
    var mathLib = {
    add5: function (a) {
    return a + 5;
    },
    mult5: function (a) {
    return a * 5;
    }
    }
    [/sourcecode]
  • Add a JavaScript file with your Jasmine tests for the code above like so :-
    [sourcecode language=”csharp”] describe("general", function () {
    it("A basic test", function () {
    expect(true).toBeTruthy();
    var value = "hello";
    expect("hello").toEqual(value);
    });
    });

    describe("stringLib", function () {
    it("will get vowel count", function () {
    var count = stringLib.vowels("hello");
    expect(count).toEqual(2);
    });
    });

    describe("mathLib", function () {
    it("will add 5 to number", function () {
    var res = mathLib.add5(10);
    expect(res).toEqual(15);
    });

    it("will multiply 5 to number", function () {
    var res = mathLib.mult5(10);
    expect(res).toEqual(50);
    });
    });
    [/sourcecode]

  • Ok so we have some JavaScript code and Jasmine tests for the code, lets add some required links to our Jasmine specrunner page so we can see the code coverage
    results output to the screen, edit the spec runner like so:-

    specrunner2

    The above screen shot shows that we have added a reference to both our JavaScript code file and the file containing the Jasmine tests.

  • Now if we browse to the specrunner page for Jasmine we will see the results of the test – green for passed and red for failed (no code coverage results yet).

    jasmineresults1

  • Now lets show the JavaScript code coverage results – which is as simple as adding in the line to reference Blanket for Jasmine:-

    specrunner3

  • Refresh the specrunner page and you will now see your JavaScript code coverage results like so:-

    specrunner4

    The screen shot above shows us 100% code coverage, so no lines of JavaScript are coloured red (not covered)

  • If I comment out one of the tests we can see the difference below:-
    specrunner5
  • And there we have it code coverage results of your JavaScript, brief post but enough to get you started I hope, next time I will add this to TeamCity and see what that gives us.


Book Review: C# Smorgasbord by Filip Ekberg

smorgasbord

Book Review: C# Smorgasbord by Filip Ekberg

About the Author:
Filip is a Software Engineer working with various techniques such as C#, WPF, WCF, ASP.NET MVC, ASP.NET and much more. Currently working at Star Republic in Sweden as a Software Engineer working with both newer and older technologies in a Windows environment, mainly focusing on ASP.NET MVC development.

During his years of Programming, Filip has managed to accomplish some of the following:
• Software Engineering Degree @ Blekinge Institute of Technology
• Managing the Software Development Company SmartIT eSolutions Sweden which focused mainly on developing software and web solutions.
• Working as an Amanuensis ( Teacher ) @ Blekinge Institute of Technology teaching Java, C++, Sql and Network-programming.

You can read more on his blog here.

I saw a tweet from @daniellangnet who said this book was fantastic and if your looking for something to read over the holidays then give this a go, I actually ordered the book without even reading anything about it, unusual but glad i did!

Chapter 1: Introduction to Parallel Extensions :- Learn the basics of paralleization, use basic Linq, and how to optimize code by introducing parallelization.
Chapter 2: Productivity and Quality with Unit Testing :- Understand why tests are import, create a test project and improve code quality.
Chapter 3: Is upgrading your code a productive step? :- How to find bugs faster, How to use Resharper to get a more manageable project and to get things done faster.
Chapter 4: Creating a challenge out of the trivial tasks :- Challenge yourself to create understandable and higher quality software.
Chapter 5: Asynchronous programming with async and await :- Identify where yo might need asynchronous processing, refactor a synchronous app into becoming more responsive.
Chapter 6: Dynamic program :- Create and extend a dynamic object by using the ExpandObject, also understand why introducing dynamic objects might cause problems long-term.
Chapter 7: Increase readability with anonymous types and methods :identify where you might have single purpose methods that you can replace with anonymous methods for increased readability and lucidity.
Chapter 8: Exploring Reflection :- User reflection to get information about types at runtime and understand more about properties and methods.
Chapter 9: Creating things at runtime :- Create your own method at runtime using Reflection, be able to read IL and understand portions of it.
Chapter 10: Introducing Roslyn :- Create a basic code analysis that suggest issues in your code, run code snippets on entire code files.
Chapter 11: Adapting to Inversion of Control :- Understand the basics of Inversion of Control, introduce a Dependency Injector into your application.
Chapter 12: Are you Mocking me? :- Create a mock of any interface and write tests that introduce

This book as you can see has something for everyone, i have thoroughly enjoyed reading it from cover to cover and will be reading a good few of the chapters again, it’s a very handy reference book and covers a number of topics that as a developer can help you explore, improve and be inspired – just as it says on the front cover.

I picked this book up on Amazon for £19 and its well worth it – recommended reading for 2013.



Practice Code Kata’s And Learn

I have been reading up on code katas and think they are a fantastic idea, for those of you who don’t know what a code kata is have then don’t worry read on.

A code kata is, as I see it, how to take a requirement, break it down into a list of simple tasks and then write the code to solve those problems, pretty much what a developer would normally do anyway but you could tackle the problem using different coding languages/styles/patterns.

The reason I think code katas are interesting is as follows:-

  1. It will help you learn to use TDD – Use Test Driven Development to write a test before you write the code, write the test, run it so it fails, then write the code to make the test pass and that’s all, do this for each part of the problem your trying to solve.
  2. Estimate how long you think it will take to complete, then time yourself and see how long you take to complete the code kata.
  3. Help improve your typing skills and learn shortcut keys as you try to be more productive and learn to do the kata quicker each time.
  4. Use them at interviews to test your interviewees, see what they come up with and how they think rather than asking them about something they googled the night before the interview.
  5. The best way to learn how to code well is to practice, just like a musician needs to practice, good developers practice too.

Good examples

As a good starting point take a look at Roy Osherove’s string calculator – this can be done using a number of different code languages.

More code Kata’s can be found below:-

Let me know if you find any more and I will add to the list.



Testing, testers and the need for them

In a profession such as software development, testing the code that your developers write is of the most important things you can do.

Working with complex requirements which can change at any time can be a challenge to say the least. Writing maintainable, bug free code is also a challenge and with the best will in the world the code your developers write is unlike to ever be completely bug free.

If you have a product for example, the code needs to have proper unit tests which are ran daily (even hourly) and when code gets checked in order to make sure nothing gets broken when you make a change. This is fairly standard but the number of places I have seen which don’t have this basic scenario is quite alarming.

When a customer asks for a new feature to the product and you don’t have proper unit tests with code coverage then how on earth will you know if you havent broken anything. To go back and test the entire application is unrealistic but if you don’t unit test the application then you cannot say for sure that you havent broken something no matter how trivial the change may be.

In my next blog post I will talk about CI (continuous integration) and how it should be setup and why it works so well.

In my opinion, software companies need testers – to have the developers test their own software is wrong, even to have other developers test other developers work is wrong, testers are professionals and they test out with the boundaries that a developer would test. Testers save time and money in the long run as the product becomes more stable, less bugs appear and your customers are happier as the code is more reliable.

Releasing code also becomes less fraught as you can have confidence in the fact that the code has been tested and has passed the unit tests.

When the tekpub videos talk about coding, Rob Conery always says if you’re not doing Test Driven Development or Unit Testing then you’re doing it wrong – I have to agree with that comment. We are software professionals and cutting corners is not what we do.