Page comments

Max Joergen — Thu, 12 Jan 2012 13:18:28 +0100

I’m really loving the template/theme of this blog. It’s simple, yet effective. A lot of times it’s challenging to get that “perfect balance” between user friendliness and appearance. I must say that you’ve done a excellent job with this. Also, the blog loads very quick for me on Opera. Excellent Blog!

brice — Wed, 30 Nov 2011 07:07:48 +0100

Hi, Good hacking. However, I might be picky here, but I think It should be mentioned : You should code your utility with API in mind, try to express in code how you want to use your API then code. I like the saying : We can't be lazy on API design. For example for your use case, I might want to use it that way : ObjectBinder carBinder = ObjectBinder.recordPojoProperties(Car.class); Car car = carBinder.get(); // … BeanProperty gearProperty = carBinder.asProperty(car.getGear()); BeanProperty minOilLevelProperty = carinder.asProperty(car.getEngine().getMinimumOilLevel()); // … Set> carProperties = carBinder.recordedProperties() Internally your code should be more "auto-documenting". For example EXReturnDeepStubs don't express intent, I don't know what it does until I look directly at the implementation. In my very own opinion you shouldn't extend it, unless you have a very specific reason for doing that. MockingCache also lies a bit as it's intent is not really to "cache". getBeanPropertyPath could be refactored. Especially in the loops to express in a more readable way what you want to do here. I think this is important as this code is tacky by definition, I mean you are using internals of Mockito, it should be rather well documented to be understandable by your coworkers or by the people that will need to maintain / extend it. Don't use StringBuffer, in Java 5+ you should use instead StringBuilder, which doesn't have synchronized cost, in your case synchronization is not needed. Pay attention to visibility, MockingCache exposes internal fields. In a more general way you should pay attention to concurrent access, or at least state that your code should't be accessed in a concurrent way. The above snippet is supposed to be ran in the thread local context. This is important as UIs events could run in different threads. Maybe such code could go to some open source library -- Brice

mike — Wed, 23 Nov 2011 13:17:16 +0100

I've started a query on the mockito mailinglist...for those interested: http://groups.google.com/group/mockito/browse_thread/thread/09367a8814561d49#

Elmer — Tue, 22 Nov 2011 14:37:00 +0100

We've been playing a little with mockito in the area of compile save ui binding. Now I'm interested in some feedback of other mockito users.

Veronica — Mon, 05 Apr 2010 19:51:57 +0200

Das Problem des erkennen habe ich mich bereits bei der Bärenpark-cam überdacht, besonderes beim Eintritt. Das Park hat eine noch slechtere Lösung gefunden, nämlich eine Änderung in der Camera-route. Jetzt sehen wir weniger Park, mehr von den schönen Aarebocht, nichts von Finns teil und mehr Überseite. Vielleicht können wir Sie durch ihren Fenster zuwinken (wenn Sie eine grosse rote HIER-Pfeile ans Fenster kleben, damit wir wissen wo). Bei mir ist einmal versehentlich einen Öelfleck aufs Fensterfolie geraten. Dass wurde dort verschwommen durchsichtig. Nach webputschen was es wieder trüb. Vielleicht lässt sich den Oberrand des Unterfolies etwas durchsichtiger machen, denn die grosse Folieteilen stören sehr. Mit einer Entscharfung geht es wohl besser.

Verena AMIRI- RYCHENER — Tue, 30 Mar 2010 13:41:51 +0200

Salü zäme, vielen Dank für die tolle idée!!! jetzt bin ich wieder 100 % Bernerin dank den lieben Wappentieren ;-))) herzliche Grüsse aus Frankreich Departement 17 im Sturm ( wieder)

Aeby — Thu, 14 Jan 2010 17:54:08 +0100

Chic! Krasser vorher/nachher Unterschied! ;-)

Gratulation — Wed, 23 Dec 2009 17:04:33 +0100

5 Jahre schon? Das ist ja toll!