Rhyous

In a previous post, Avoiding the MSVCR100.dll, MSVCP100D.dll, or MSVCR100D.dll is missing error, I explain what the MSVCR100.dll is and how to solve problems with it.

Many have asked for an MSVCR100.dll download. Turns out that Visual Studio has a redistributable folder that contains these dlls. So I zipped it up and I am redistributing it.

Here it is:

Download MSVCR100.dll and MSVCP100.dll

So my blog was down and I didn’t know. The mysql server and CPanel were down, actually.

I decided I should set up a monitoring service so I set out to find one.

I found this article:

http://mashable.com/2010/04/09/free-uptime-monitoring/

This was the first one on the list and it will monitor up to 50 sites for free  every 5 minutes and try to send you email or texts if your site is down.

http://www.uptimerobot.com

Google pulled this site up and while it only monitors one site for free and only at 30 or 60 minute intervals, it seems to have some statistics for you.

http://www.siteuptime.com/

This is to cover development related training, (so no Human Resources (HR) training is listed here).

Why training does not occur

The industry is full of companies that do not invest in training for their developers. There are many reasons training does occur and for every company these reasons may be slightly different.  Here are some that seem prevalent.

1. There is an assumption that developers do not need training.
2. They assume developers train themselves.
3. They cannot afford training.
4. They haven’t even thought about it.

Of course, many software development companies provide excellent training, so this article may not apply to them.

Why you should train your developers

Training is extremely important and this article exists so that if you are in a software company that is failing to train your developers, your development department can take steps to improve this.

To make correct decisions

Many software development companies fail in many areas. Training will not guarantee success in these failed areas, but it will increase your odds of success significantly. Often developers are treated as experts and analysts for tools and processes to perform their jobs. Developers often get to choose their source control tool, 3rd party libraries, the branching strategy, and more. Unfortunately, most developers are not trained System Analysts so they do not actually have an expertise in how to locate multiple products that feel a need, research which is best, and choose the one that is best for the company. Instead, the choice is often made because it is the first tool or process the developer found or already knew about that works for their very narrow need at the moment.

If your developers are well-versed in a topic and know the options and the pros and cons of each option, they are more likely to make correct choices for your company.  Ask yourself and your team about your current tools and processes. Is your development department just using these tools and processes because they are the most common, or because a skilled analyst determined that process fit your business?

When you hire a new employee, or when you implement a training program among existing employees, it is difficult to know where a developer stands in regards to training. If you want to find out where a developer is at, and help them move to the next level, you need a tracking system.

To grow as a developer

You may find that developer grow at a fast rate their first few years. But then, this growth may stop. A developer’s skills may stagnate. They know enough to do their job so they don’t continue to learn.  This is a problem because new technology always comes out and new tools are released to aid in their job.

To maximize productivity

A trained developer should produce code faster and with higher quality.

Software Development is always improving and something that may take a day today, might take 30 seconds and one line of code a year from now due to either a new tool or a new library.

To improve quality

There are a lot of bugs per lines of code and training, especially on quality topics such as design patterns and unit testing, can really improve the quality of a product.

How to track a developer’s training

I designed a simple tracking system. I made a list of topics (which are by no means complete) and subtopics. I gave each sub topic three levels to show continued growth.

The following is a spreadsheet version of the simple Developer Tracking System I created.

As a Google Doc: Developer Training Tracking Checklist
As Excel: Developer Training Tracking Checklist
As Excel (inverted) Developer Training Tracking Checklist – Inverted

Basically, the items that you should train on are as follows:

Here is the key:

Key or Legend

Training Topic = A broad general development topic. Example: Source Management
Sub Topic = A more specific development topic. Examples: Source Control Tool, Chosen Branching Strategy
Level 1 = Often over the shoulder training of a new hire. A basic overview that is enough to get them working. For example, what are the basics for using TFS. 1-4 hours. All level 1 trainings should be provided within the first three months or at first use. Level 1 can be marked off without training if the employee demonstrates they are already at a higher level.
Level 2 = Usually in a formal training or an online training. A more in-depth overview of the sub topic. 8+ hours. All level 2 trainings should be complete by the end of year 1. Level 2 can be marked off without training if the employee demonstrates they are already at a higher level.
Level 3 = Expert level training. This could come from combining a few trainings, such as one or more Text Books, Online Research. 24+ hours. Level 3 trainings take time. The should begin after the first year of employment (unless a job requires it occurs earlier) and one or two should be completed each quarter. If an employee thinks they are already at a level 3, they should create a portfolio of information describing why they are at level 3 and present to a peer group of four or more individuals. If at least three of the four agree, then Level 3 is passed.

Training Types

FT = Formal Training. Hopefully in a classroom by a technical trainer.
OR = Online Research. Employee reads blogs and articles about the subject and indicate the articles and blogs read.
OT = Online Training. A formal training delivered online.
TB = Text Book. A book about the subject. Indicate which book. Also, the book should be read by multiple developers who should meet every other week to discuss the topics in the book.
ST = Shoulder Training. A person trains from over the shoulder. You may want to track who provided the training.

Hopefully if you are a VP of Engineering or CTO of a development company, you can take this and implement this in your environment.

Friday was my last day as an employee at LANDesk. After more than seven years, it was emotionally painful to leave. I have lots of friends and co-workers who I trust and respect that I’ll likely see once a year if ever again.

While on one side change can be sad, on the other it can be extremely exciting!

I have accepted a new position as a Lead Software Developer and start one week from today. My new company will be called Caradigm. GE Healthcare and Microsoft are coming together to form this company and each will own 50% of it. Click the image below to read more about it.

This is going to be a fun time working for a new IT healthcare solution.

The following are Unit Test best practices and guidelines:

1. Test one object or class per unit test class.
   Yes, you should refactor your code if you cannot test one class only.
2. Name your test class after the class it tests.
   If you have a class named SomeClassY, then your test class should be named SomeClassY_Tests.
3. Perform one test per test function.
   The test class can have as many functions as you need. Perform one test per function. That doesn’t mean one Assert call. Multiple assertions might be needed to perform one test.  Think of it this way. When a test fails, you should know exactly what failed and why just because of which test function failed.
4. A unit test should run on the Build and Continuous Integration (CI) systems.
   Unit tests are there to help you succeed and prevent you from failing. If they run rarely, they rarely help. They should run every time you check in code and every time your build kicks off. You should be automatically notified if any code you wrote breaks an existing Unit Test.
5. A unit test should never alter the system in any way.
   Don’t touch files, databases, registry, network, etc… A test that does so is a functional test not a Unit Test. If an object cannot be tested without touching the system, refactor the object to use an Interface (and if needed a wrapper) for interacting with the system so such can be faked, or mocked with a tool such as RhinoMocks or MOQ. This is important because if a Unit Test is running on the Build or CI system, you could actually introduce a change to the system that hides a bug and allows the bug to exist in a released product.
6. Make the test function names self documenting.
   This means if you want to test passing in a bool to FunctionX you might call your test functions something like this:
   FunctionX_True_Test()
   FunctionX_False_Test()
   Think of it this way. When a test fails, you should know exactly what failed and why just because of the function name.
7. Never assume 100% code coverage means 100% tested.
   For example, 100% coverage of a function that takes a string as a parameter might be 100% tested with one test. However, you may need to test passing in at least five string instances to avoid all types of bugs: expected string, unexpected string, null, empty, white space, and double-byte strings. Similarly a function that takes a bool parameter should be tested with both true and false passed in.
8. Test in the simplest way possible.
   Don’t elaborate, don’t add extra code. Just make a valid test as small as possible. Warning! That doesn’t mean you can forget the best practices and guidelines above. For example, if the simplest way is to test everything in one function do NOT do it. Follow the best practices and guidelines.
9. Get training and keep learning about Unit Testing.
   You won’t do it correctly without training and continued learning. It doesn’t matter if you do your own research and train yourself by reading online articles, blog posts, or books. Just get yourself trained and keep learning. There are many test frameworks, mocking frameworks, wrappers (such as System Wrapper), and encapsulation issues, and without training you may end up with Unit Tests that are not maintainable. You will find many opinions about best practices, some matter, some don’t, but you should know each side of the opinions and why those opinions exist whether you agree with them or not (this list included).

I hope this list helps you.

If you have a best practice not on this list, or you want to comment on one of the items, or even disagree, please comment.

Return to C# Unit Test Tutorial

Interface-based design leads to good Unit Tests because you can more easily have a separation of concerns, limit the test to one object, and eliminate dependencies by not having to have “real” dependencies available to test a portion of your code.

I am going to explain this by example.

First, let me remind you of some rules for writing good Unit Tests:

1. You don’t touch the system so Unit Tests can run on a stable build device without corrupting the build system.
2. You don’t have external dependencies so the build system can run in an isolated environment.
3. The tests should run quickly.
4. Each test should test one thing only.

Imagine you have code that tests authenticating to a UNC path.  You have these two classes:

• BusinessObject
• NetworkShare

BusinessObject contains an instance of NetworkShare.  The code is not really significant as this is theoretical. We’ll get to code in the next few articles.

You need to write Unit Tests for BusinessObject.cs.

Why is this a problem? Because it requires a system with a UNC share to run the class and so testing is difficult.

Now, imagine that BusinessObject.cs didn’t actually have an instance of NetworkShare, but instead an Interface was created called IAuthenticateRemotely. And Your code now includes these files.

• BusinessObject
• IAuthenticateRemotely
• NetworkShare : IAuthenticateRemotely

Now BusinessObject has an instance of IAuthenticateRemotely instead of an instance of NetworkShare.  Now you can write Unit Tests for the BusinessObject class by simply creating any fake class in your Unit Test code that implements IAuthenticateRemotely. Your test class would simply be a fake. Lets say the IAuthenticateRemotely had a bool Authenticate() function. You would create a fake class for your test and implement this function as follows.

public bool Authenticate()
{
    return true;
}

Notice that the function doesn’t actually do anything. That is because a Unit Test for the BusinessObject class only needs to test the BusinessObject class.

Please feel free to make any comments as necessary.

Return to C# Unit Test Tutorial