How unit tests reveal bad architecture
Unit tests are something awesome: they not only tell you if your changes will break everything but also when you need to mock out 10 dependencies you know something is wrong.
Having to mock out too many dependencies will make people less likely to write proper tests for it. Seems like writing tests is hard enough for your average developer so why make it harder ? I don’t have an upper limit on how much mocks are too much but when someone says “I don’t want to test this, I’ll have to mock half of the system”, that’s when you’ve gone over the limit. That’s when you should start splitting into sub-systems.
Something are better left to integration tests also; indeed I don’t think everything needs to be unit tested. At one point everything has to work.
My scope is dying
Just after putting a circuit you want to test it. That’s when you power on your ‘scope. The last thing you want to see is a failure on the self-test… .
At least I have one channel still working, I’ll try to debug the scope with that (and try not to kill myself with high-voltage)
String formatting
Today I learned about String.format. I always used MessageFormat.format before but this is way better ! Props to Olivier who told me about it.
Certified ScrumMaster
Now that I am no longer a ScrumMaster at my work place, I’ve received my certificate that I’m a ScrumMaster. Awesome.
I do wonder why they feel the need to certify people. Does it guaranty something ? What would stop me from doing anything I want anyway ? What if I’m unable to see what I’m doing wrong ?
Meetings are not work hours
- What do you mean you haven’t got any work done today ?
- I was in meetings with you all day
- I got stuff done
- Done ? You must not have lots of criteria to mark a task as done
Bullshit Driven Development
Bullshit Driven Development is a style of development that forces you to think about the company politics before anything else. You need to build up an architecture that is so complex that other departments and so future-proof that other departments has no chance to attack it. Bonus points if you twist facts from the other departments in an evil way to thicken the architecture.
It’s not like NPEs are a problem
try {
integrationService = ServiceLocator.lookup(IntegrationService.class, "IntegrationServiceBean");
} catch (final RuntimeException e) {
System.out.println("RuntimeException");
return null;
}
This is all running inside a web container. I hope I never have to debug that code.
This doesn’t do what you think it does
I’ve seen this one countless times. == on a string isn’t the same as .equals; one compares the instance and the other compares the content.
if (localeCode == null || localeCode.trim().isEmpty() || localeCode == "?")
The joys of Xorg and nVidia drivers
I just upgraded Xorg on my debian machine and most GTK 2 widgets lost their borders. How annoying. Turns out the latest xserver-xorg-video-nvidia driver isn’t compatible with the latest Xorg ABI but; this driver doesn’t tell you, a more recent version will complain:
================ WARNING WARNING WARNING WARNING ================
This server has a video driver ABI version of 11.0 that this
driver does not officially support. Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
=================================================================
(WW) NVIDIA: The driver will continue to load, but may behave strangely.
(WW) NVIDIA: This driver was compiled against the X.Org server SDK from git commit b6c7b9b2f39e970cedb6bc1e073f901e28cb0fa3 and may not be compatible with the final version of this SDK.
(WW) NVIDIA: This server has an unsupported input driver ABI version (have 13.0, need < 13.0). The driver will continue to load, but may behave strangely.
The solution was to carefully downgrade xserver-xorg-core to 2:1.10.4-1 (that required downgrading xserver-xorg-input-evdev xserver-xorg-input-wacom too). Back with Xorg ABI 10 and everything works ! I now have border on my widgets !
sudo apt-get install xserver-xorg-core=2:1.10.4-1 xserver-xorg-input-evdev=1:2.6.0-2+b1 xserver-xorg-input-wacom=0.10.10+20110203-1)
The Singleton Pattern Revisited
Need to test a singleton ?
Suppose you have singleton class A:
class A {
public static A getInstance() {...}
private A() { ... }
public int doStuff() { ... }
}
How can you test it if you can’t use your mocks ? Simple put it in a package and make ASingleton that creates A using a constructor package default ! Since your tests run in the same package you will be able to extend it and use your mocks while still having a semi-private constructor.
class A {
A() { ... }
public int doStuff() { ... }
}
class ASingleton {
private ASingleton() {}
public static A getInstance() { ... }
}
Recent Comments