Everyone is always trying to use the best possible computers to do their jobs. Developers buy high performance machines so they can write code faster. Some improvements can be made to your development speed without going and spending large sums of money amassing expensive tools and machines.
As any craftsman will tell you, "you need to have the right tool for the job". A lot of times there are quick queries that we need to write to check bits of data and such. If this is what you're doing, it is sill to open up SQL Server Management Studio just to check this. The overhead of opening up and application and using it will have you wasting plenty of time. Use a tool like LINQPad, so you have a lightweight application you can easily open and work with.
If you need to make a code change to a config file or some very minor edit to a text file of a variety of languages I recommend using a lightweight text editor like Notepad++. This will save you a lot of time over opening Visual Studio, and it is much more advanced than Notepad. It has a good amount of advanced features and isn't a full-featured IDE like Visual Studio.
Using these lightweight tools in combination with the heavy-duty tools like SQL Server Management Studio and Visual Studio will make things a lot easier.
Welcome back for another exciting tip for those developers writing unit tests. Today we will be looking at assertions in unit tests.
Only Assert On One Case Per Test
When people start writing unit tests they do the natural thing with their Assert statements; they write a bunch of them in the test. This makes a bunch of sense, because you don't want to repeat yourself in your tests. This is not bad as long as all of the asserts are asserting the same expectation with different values. If you are testing different cases then they need to be separate test.
The reason for this is that unit testing frameworks tend to abandon a test as soon as an assertion has failed, so you get less information if you have grouped many tests cases into one test method. By making sure that every test method contains only assertions dealing with the case in question, we will garner valuable information from each test. Maybe we will discover that the cases with negative numbers and the edge case, zero were the ones to fail. If we had grouped the assertions into one method, we would have only had one failed assertion and wouldn't have gotten all of this info. For example we might have only had zero fail if its assert was first, and then we would be thinking this was a problem with the edge case when it was really a problem with all numbers less than one.
Group Your Asserts Together
If you can, try to keep your asserts together at the end of the method. This will make them much easier to read and keep track of. I've seen some tests where someone wanted to assert before changing a value. A better way to handle this is to store the value you need to hang on to in a variable and assert at the end with everything else. This will make your tests a lot more maintainable, and someone down the road editing the test will sure thank you.
Keep Your Assertions Concise
You should have no logic in your assertions. Don't ever access a property or call a method in an assert statement. These are what someone looks at to try and figure out what is going on. Use simple, concise variable names which explain things. If assertions are cluttered and confusing, your tests will be very difficult to use.
Remember to be careful with your asserts. They should be clean, easy to read, and managed nicely. Their maintenance is extremely important to your tests.
In Visual Studio there are code snippets which can be used with auto-completion. These are a lot of the common structures used by developers when writing code. They are customizable using Visual Studio, but I find it much easier to use editors like Snippy. So if you were not using snippets because one of them was not exactly the way you wanted it to be, give a snippet editor a shot.
I highly recommend creating your own snippets as well as customizing them. I for example use one to create tests. I type 3 letters hit tab and type the name of the test method. This saves me the time of typing the attribute as well as "public void" and some curly braces every time I write a test. Yes, I know that a lot of these are simple little things, but trust me when I say that they all add up into faster development. How do you think all of the visual studio add-ins make money? They allow for a lot of little speed boosts which keep developers coding faster.
A lot of applications allow you to work with a group of text at a time. For the purposes of this post I'll call them "words". When I say a lot of applications this includes the powerful IDE called Notepad. This cool trick can be applied in a lot of different places. I am sure you'll figure out some interesting uses for this.
The key (literally) to achieving this productivity from working with words is the Ctrl key. By holding it in combination with other keys we can work with words. The three main things I want to discuss when working with words are: moving from over a word, selecting a word, and deleting a word. As you can probably guess to move through a word you use Ctrl with an arrow key. To select a word you hold Ctrl as well as Shift while using the arrow key. To delete a word you can use Ctrl in combination with Delete or Backspace. (Yes, I lumped delete and backspace together even though they are technically separate operations.)
Here is a demonstration in Visual Studio showing how to move over words followed by select words followed by deleting words.
I was copied on an email recently from someone reluctant to begin writing unit tests for code. One of the complaints about the idea of starting late game adding in testing was an interesting one. The person mentioned that because they're starting to test so late that they will not get "all the benefits of TDD". Well, that person is correct. However, that should not stop anyone from making things better.
Recently the "boy scout rule" was brought up to me in the context of coding, and I admit I'd never thought of how well that example applies. The scouts have a rule to leave a camp site cleaner than they found it. This is a great idea since it means that gradually overtime you will be making improvements. No one is saying to go and spend a month cleaning things. That would be a HUGE waste of developer effort from the customer's perspective.
A good rule to live by and one I try to practice regularly is to refactor and clean a little bit every time you touch a file. Even if this just means adding a test or even renaming a bad class, interface, or variable name, the important thing is to make these minor improvements every time you get into some piece of code.
Another complaint about switching was that developers would be spending 50% of their time writing tests. Well I will say that that isn't quite right, but the idea there is accurate. The amount of code written is about half test code and half production code. The advantage of having the tests is less time spent debugging and fixing. Most developers have heard about the cost to fix bugs at different points during the development lifecycle, but I will summarize it as, "the sooner you catch a bug the cheaper it is to fix". If we have tests in place we find the bug sooner. This means the end cost is less, so writing the tests should save us money during development as well as during maintenance.
I admit when I first got introduced to testing I thought a lot of the same stuff. I figured the tests would slow down the development and wouldn't help very much. I figured there would be all these issues, and I'll also admit that it is pretty tough to start doing. Once you start writing tests for things you start to see some of the benefits. The best thing to see is when you change some piece of code and something seemingly unrelated has a test break. That is when you realize the connection and prevent a bug from being created. That is one of the best aspects of testing.