Monthly archives: November, 2015

Nov24201524 November 20156 December 20159Commentsby Gregor Suttie

My list of best practices

Posted in Best Practices

Over the 19 years I’ve been a developer I can say I have seen some good, some bad and some ugly practices, but lets remain positive and here is my list of best practices/thoughts to which I hope have adopted to over the years:-

  • Make sure you have the latest version of the code before you check in (if you’re using SVN).
  • Small commits and commit often, after you’ve run your tests locally that is.
  • Don’t be the developer who is always breaking the build, check that your code builds on the build server.
  • Check your builds daily, make sure builds aren’t left broken for days.
  • Automate builds/deployments where practical, manual deployments are a no-no.
  • Measure code coverage as it can point to bad smells in your code base.
  • Write Integration tests and Unit Tests which add value, not just to get code coverage up.
  • Clean up after you, don’t leave stuff lying around.
  • Make sure your log files are actually helpful, don’t fill them with useless info and make the log level easily configurable.
  • If you create Helpdesk tickets then give some meaning to the piece of work, don’t be lazy.
  • Don’t check in Third Party Nuget packages to source control – keep your repositories lean as possible.
  • Begin Transaction *put your update statement here* Rollback Transaction, trust me this can save your ass.
  • Leave the code in a better place than it was before you touched it, remove unused code, unused using statements, refactor duplicated code etc.
  • Get the database Id in SQL using ‘select db_id()’ and trace it so you know exactly what your stored procedure is doing
  • At the daily stand up, have a note of what you were working on, “I don’t know what I did yesterday helps no one”.
  • Try and figure out why its broken, don’t leave it for others to fix, you wont learn much doing that.
  • Take an interest from development right through to deployment, the more you know the more you’ll understand and can perhaps help out.
  • We are professionals, act like one and take pride in your work.

I will add to this list over time, feel free to comment on any of this and tell me your thoughts.

Catch me on twitter @gsuttie


Tags:

Nov22201522 November 201522 November 20151Commentby Gregor Suttie

Continous Deployment – Free Code Coverage tools Part 2

Posted in Continuous Deployment

ReportGenerator

Ok so after part 1 now we have code coverage results it would be nice to see a report of this so we can display this on our build server after our tests have run.

To do this we can use ReportGenerator which is also on Github and an executable.

reportgenerator

This can also run be run locally or on the build server which is nice as its a pretty useful feature to see your code coverage after a build on your build server.

coverageReport

The nice part being we can drill into namespaces and see what’s covered and what’s not.

coverageReport2

Now over time it would be great to see code coverage historical results and see the coverage going up, well ReportGenerator now does historical graphs which is just another type of chart which we can very easily have generated for us.

When I add the flag -historydir:SOME_DIRECTORY I can have the report keep a chart of coverage of a history of time/builds so we can see our code coverage going in the right direction over time which is what we are after.

ccup

In the above screen shot as I write tests which cover my code and do builds I can see a graph over time of the coverage going up which is exactly what we are after, add more code that’s uncovered and the graph will trend downwards which isn’t what we are after.

I hope this helps someone out there, feel free to get in touch with questions, best place to get me is on twitter @gsuttie

Fore more information about report generator check out the guy who wrote it https://github.com/danielpalme/ReportGenerator. Big thanks to Daniel Palme who you can reach out to on twitter @danielpalme.


Tags:

Nov10201510 November 201510 November 20152Commentsby Gregor Suttie

Continous Deployment – Free Code Coverage tools Part 1

Posted in Tools

    OpenCover

If you’re looking for some free code coverage tools then the good news is look no further than OpenCover.

OpenCover can be run from the command line, which also means you can run it as part of your continuous deployment all for free, I like free.

If you’d like to get code coverage built into Visual Studio then look no further than the extension called OpenCover UI, this will give you code coverage results and show you which lines of code are covered by your tests, giving you no excuse to not test as much of your code where possible.

I created a very simple Calculator class library project and then add a class library for testing my calculator class, I’ll spare you showing the simple code, but here is a screen shot of me having ran the tests using OpenCover within Visual Studio.

coverage

The Above screen shows the lines in the class which are covered by tests in green, red are lines uncovered by any tests, below that is a break down showing the percentages of code covered and on the right is the test explorer showing the list of tests available.

If you want to run OpenCover within Visual Studio then add it via Extensions and Updates in the Tools menu of Visual Studio.

If you want to run OpenCover from the console then you can run it via the command prompt, doing it this way has much more flexibility as you can filter out test projects and generated code etc using the arguments you pass into the OpenCover executable.

opencover

Now once we have the code coverage within Visual Studio we can also get code coverage on our build server which is really what were after, due to OpenCover being an executable this is very easy to set up, you can find all the info you need to do this at the OpenCover Usage link.

In the second part of this blog post I’ll show how to generate a web page to show off these results which can be easily incorporated into your build server after each build, this will also show history of code coverage over time in case you want that feature too.