About
This is the M Cubed Software weblog. To find out more about us head to our about page.
Search
Feed
Archives
- March 2010
- February 2010
- January 2010
- November 2009
- August 2009
- July 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
Where To Use Unit Tests
Posted on 22/07/2009 at 10:33 PM in Coding
So I’ve started to do a lot more unit tests than I usually do while working on Minim 2.0. I’m not doing test driven development, I made my thoughts on that clear in an earlier post. However, I feel a lot of the issues people have with unit tests and their use are misplaced. So I thought I’d outline where and why I’m writing unit tests. There are a few rules I have about whether a method should or should not have unit tests.
Trivial methods don’t need tests
If you are unit testing properties you are insane. If you are unit testing methods with one or two lines you are insane. There is no need to test these methods. You can understand how they work quickly and easily and if you don’t because these few lines are very complicated then you need to break your code up into a few more lines.
Methods with complex logic need multiple tests
Any methods that have complex logic should have multiple unit tests. The reason is that complex logic is not as easy to understand at a glance, even if you wrote it. As such it is much easier to break. There are very mixed opinions about using automated tests to help develop an app, but almost everyone can agree that automated tests are great if they stop you breaking good code.
Depending on the complexity of the method you should have multiple tests. Obviously you can’t test everything but try to cover the most common case and any edge cases you think could cause problems. For example, if your method should do something differently depending on whether a flag is YES or NO then test both the YES and NO cases.
Methods used by multiple parts of the app need tests
These are possibly the most important methods to test. These are the ones that are accessed by multiple parts of your app so you will likely be changing quite often. The problem is that while you change it for one part of your application, you may forget to test all the other parts of your application that use it so it is good to make sure that these other parts get what they expect from the method.
If you fix a bug in a method then write a test for it
What is the point in fixing a buggy method if you’re just going to break it again later? Write tests when you fix a bug to make sure it stays working. This method also means your test suite can grow organically.
These 4 rules are what I use to decide whether I should write a test or not. Often I’ll work on a feature and get it working and then go through my methods and decide what would be worthwhile writing tests for. This way I can focus on development and then spend a few hours afterwards concentrating on the testing. The added benefit is that I can think again about how my code works, which may lead me to find issues that a unit tests can’t fix.
(2) Comments
Designed by M Cubed
Posted on 07/07/2009 at 05:41 AM in M Cubed News
Today is the start of a new era for M Cubed. There are 3 exciting things happening and the first is the most obvious: a new website design. We’ve gone through the whole site and redesigned everything from the bottom up.
The biggest change to the site is the new store, which allows you to buy multiple applications at the same time, as well as our new 5 user licences which offer a discount over the cost of single user licences if you need to buy in bulk
M Cubed times 2

For a long time M Cubed has been a single person operation, with me handling everything from programming to application design to the website to support. Well I’m pleased to announced that I am no longer working alone. May I introduce my new partner in crime: Fabio Basile.
Fabio is joining M Cubed to work on design and also some programming. This will help us get updates out faster, while making them look much better.
Design & Conquer
But Fabio isn’t only going to be designing and coding stuff for M Cubed. If you look at the navigation links at the top of the page you’ll notice there is now a “Design” link. Click on this and you’ll be taken to a wonderful world where you can get your design done by M Cubed.
Yes, no longer content with just producing amazing software, we are also going to offer amazing design services. We will be offering icon design, website design, user interface design and also Django server-side programming. If you’re interested then head over to our Design section to find out more!
M Cubed has gone through quite a few significant changes recently, but they will all help us produce much better software for you much more quickly than before. Watch this space as there are exciting things coming soon.