Wednesday, July 17, 2013
Global state (and singletons) is a big problem for testing because the global state cannot be controlled by the tests.
Dependency injection enforces the order of initialization at compile time. No magic behind the scene, that singletons get initialized and method talk to each other without the programmer knowing it.
Sunday, July 7, 2013
The constructor should have the objects you need as arguments. Don't use locator (object through which you get the object you actually need). In a test like this it is a lot easier to construct! You can just construct the objects needed. You don't need to construct the locator first and then reach in the locator to get the object you actually need.
--> This is law of demeter. Don't pass around objects you don't need. You don't want to know about objects you don't need.
DO this:public House(Door door, Window window)
_door = door;
_window = window;
NOT this:public House(Locator locator)
_door = locator.getDoor();
_window = locator.getWindow();
Wednesday, July 3, 2013
He says something brilliant:
There is no secret to writing tests...
... there are only secrets to writing testable code!
Unit Tests require a separation of instantiation of the object graph from the business logic.
- do not use new(...) in the business logic. Use Factories.
- do not use global variables/state
- no static methods
Sunday, June 23, 2013
Recently I found these videos about writing testable code and found them very helpful.
Sunday, March 31, 2013
Saturday, March 30, 2013
Nice presentation he had at google:
Wednesday, March 27, 2013
Thursday, February 28, 2013
Saturday, August 25, 2012
I like the following quote which I found on codinghorror:
[As Steve points out this is one key difference between junior and senior developers:]
In the old days, seeing too much code at once quite
frankly exceeded my complexity threshold, and when I had to work with
it I'd typically try to rewrite it or at least comment it heavily.
Today, however, I just slog through it without
complaining (much). When I have a specific goal in mind and a
complicated piece of code to write, I spend my time making it happen
rather than telling myself stories about it [in comments].
Saturday, June 2, 2012
Recently i found out that there is a thing called "coding dojo". The point behind it is that software developers want to have a space to
learn new stuff like processes, methods, coding details, languages, and
whatnot in an environment without stress. Just for fun. No competition.
No results required. No deadlines.
Some days ago I joined the Zurich coding dojo. We were three programmers with different backgrounds.
We gave ourselves the task to develop a method that takes an input
value and returns its prime factors. We did pair programming and every
few minutes we switched positions. We used test driven development. The
chosen programming language was Ruby.
I haven't really done TDD before. It was pretty interesting to see the algorithm develop following the testcases.
We started with the first test input=1 then developed the most
simple productive program that passed this very first test. Then we
added the next test input=2 and implemented the productive code. We kept
adding tests and made sure all tests are passed until we had the
When we improved the performance of our code we saw the value of
the tests we wrote before. Of course our first performance improvement
broke several tests.
It was a very interesting experience to see how other developers
think and how they work. I will participate at the dojo again and can
warmly recommend it to anyone. There are coding dojos all over the