You must write unit tests for your code
I admit I'm late to this "party" and really only started writing unit tests in the last 2 years.
Ok, my bad....because I understand it is critical to write unit tests as you write your code. I get it. And now, so should you if you haven't already.
I mentioned the idea of a engineers "prime directives" previously. Well I think writing tests for your code is a prime directive. There's lots of good articles available with benefits, enablers and rationale. Here's some which resonate with me to make the case for writing unit tests.
Its easy. There are some great and easy to use testing tools available including Jasmine for browser, which we use on our current project, Mocha which I've used on node.js and Jasmine for node.
These tools are very easy to use and simple to get started with. Plus they'll run the tests very quickly.
It stops code rot. Unit tests are the key foundation which makes refactoring possible (Please see my previous post re refactoring.). I will feel much more confident about making code changes if there's a solid body of tests to quickly run and prove my changes worked. I can change and optimize code and many tests should still pass. Consider it a gift to your future self!
It satisfying. It satisfying to know your code is well tested, to know it works. Red bad, green good.
It enables automation and faster test cycles. The big design, develop and test cycles can be a killer. Test automation can cut down on these cycles and make it easier to release smaller and more frequently.
It decouples you. Consider this, you will find it much easier to get onto the next cool project if you can transition your code and a great way to do that is to have unit tests which others can run and use.
A key design pattern which enables unit testing is Dependency injection. If you inject or pass in dependencies to objects/modules then you can replace those dependencies with mock objects and thus more easily isolate and test that code. So make dependency injection part of your coding practice. Separate construction from business logic. Its a key enabler for unit tests. More enablers here.
Guideline: from what I've read you should almost have as much unit tests as you have code. I understand it may not always be possible to have a test for every possible code condition but I think you should have tests for key functionality and aim for 50%+ test coverage at least in the non-view (ui view interactions can be more difficult to test). If you can do more then great!
That is a non-trivial amount of work and has to be considered in estimating. From now on, my estimates will include an additional percentage to allow me time to write unit tests
Guideline: Every time you fix a bug, plan to first add a failing test (or more), then fix the bug, then retest.
Guideline: write good unit test code. Take care when writing tests. Don't duplicate test data because when it changes you'll have to change in multiple places; if you use mock data then put that in a function at the start and reuse. Test one condition per test (when I started I bunched a number together, but when it failed its hard to know which failed..doh!).
On Phase1 of our current project we created approx 50 Jasmine tests. Now in Phase2 we're at 91 Jasmine tests and passing. My goal is that the frontend team double that number again in the next month. Yes, this is writing some tests after the fact but it is a positive incremental step. On my next project I will write more tests when writing the code. Plus we've also written node scripts to test the apis used which have found a number of issues. So our automated test coverage is definitely improving.
We have not yet used a continuous integration tool but would like to set that up to auto run tests.
So....I hope this changes your coding practice because even though I'm late, if I can learn the error of my ways then so can you. Please do.
This party is gonna keep going and this is one party you cannot miss.
Ok, my bad....because I understand it is critical to write unit tests as you write your code. I get it. And now, so should you if you haven't already.
I mentioned the idea of a engineers "prime directives" previously. Well I think writing tests for your code is a prime directive. There's lots of good articles available with benefits, enablers and rationale. Here's some which resonate with me to make the case for writing unit tests.
Its easy. There are some great and easy to use testing tools available including Jasmine for browser, which we use on our current project, Mocha which I've used on node.js and Jasmine for node.
These tools are very easy to use and simple to get started with. Plus they'll run the tests very quickly.
It stops code rot. Unit tests are the key foundation which makes refactoring possible (Please see my previous post re refactoring.). I will feel much more confident about making code changes if there's a solid body of tests to quickly run and prove my changes worked. I can change and optimize code and many tests should still pass. Consider it a gift to your future self!
It satisfying. It satisfying to know your code is well tested, to know it works. Red bad, green good.
It enables automation and faster test cycles. The big design, develop and test cycles can be a killer. Test automation can cut down on these cycles and make it easier to release smaller and more frequently.
It decouples you. Consider this, you will find it much easier to get onto the next cool project if you can transition your code and a great way to do that is to have unit tests which others can run and use.
A key design pattern which enables unit testing is Dependency injection. If you inject or pass in dependencies to objects/modules then you can replace those dependencies with mock objects and thus more easily isolate and test that code. So make dependency injection part of your coding practice. Separate construction from business logic. Its a key enabler for unit tests. More enablers here.
Guideline: from what I've read you should almost have as much unit tests as you have code. I understand it may not always be possible to have a test for every possible code condition but I think you should have tests for key functionality and aim for 50%+ test coverage at least in the non-view (ui view interactions can be more difficult to test). If you can do more then great!
That is a non-trivial amount of work and has to be considered in estimating. From now on, my estimates will include an additional percentage to allow me time to write unit tests
Guideline: Every time you fix a bug, plan to first add a failing test (or more), then fix the bug, then retest.
Guideline: write good unit test code. Take care when writing tests. Don't duplicate test data because when it changes you'll have to change in multiple places; if you use mock data then put that in a function at the start and reuse. Test one condition per test (when I started I bunched a number together, but when it failed its hard to know which failed..doh!).
On Phase1 of our current project we created approx 50 Jasmine tests. Now in Phase2 we're at 91 Jasmine tests and passing. My goal is that the frontend team double that number again in the next month. Yes, this is writing some tests after the fact but it is a positive incremental step. On my next project I will write more tests when writing the code. Plus we've also written node scripts to test the apis used which have found a number of issues. So our automated test coverage is definitely improving.
We have not yet used a continuous integration tool but would like to set that up to auto run tests.
So....I hope this changes your coding practice because even though I'm late, if I can learn the error of my ways then so can you. Please do.
This party is gonna keep going and this is one party you cannot miss.
Comments
Post a Comment