YouView is a Smart TV service in the UK, a spin-off of a BBC RnD project which runs on Set Top Boxes and certain Smart TVs. I worked on the core UI for years and thought I’d share some insights into best practices when building applications for such resource constrained devices.
It gets scary out there sometimes. During my freelance career I’ve worked at a lot of different companies and have seen such coding horrors as you cannot imagine. So I thought I’d start immortalising some of them – so that we can all learn better coding practices, by looking at the bad.
Starter for 10 – What’s wrong with this picture?
public function doSomething(stuff:String):void
var newPixels:BitmapData = new BitmapData(someUint, someUint, true, 0);
someBitmap.bitmapData = newPixels;
Did you spot the fubar? It’s not an obvious one. Continue reading CODING WRONGS – Where do I start with the bad?
A couple of years ago, I created an object pooling utility for a games project I was building in AS3. Since then, I’ve used it quite a few times, in order to speed up apps and improve resource management, easing the load on the garbage collector by reusing objects instead of recreating them. Continue reading Loan Shark – fast object pooling utility
You need to use some kind of Dependency Injection (DI for short) to provision some System Under Test (SUT for short) in tests you’re writing, but can’t or don’t want to use a DI framework to do so.
Alternative titles for this post include:
- Dependency Injection without a Dependency Injection framework
- Why misusing the default namespace for tests is evil
- Make code more testable without completely messing it up
I recently had a bit of a shock while reviewing someone’s code, finding the following line in one of their unit tests:
Where: sut is their System Under Test and verify is the part of the Mockito Flex framework.
Exercise for the reader: What’s wrong with this picture?
The answer: You cannot expect Mockito to verify that something was called on anything that isn’t a mock! How the hell is it supposed to know?
At least, if attempting to stub a method of a non-mock, you’ll get a handy error telling you not to be so damn silly. But, in this case, the verify will always work. So the test will pass, but it isn’t actually verifying anything! Where do I start with the bad? This is the worst kind of test, since it provides a false sense of security on the robustness of a system. Thankfully, all the tests in this codebase had called their System Under Test either sut, _sut or SUT, so it was pretty easy to get Hudson to mark a build as unstable if it finds such madness.