Comments for Schauderhaft

Comment on Passwortprüfung in Java by john

john — Tue, 07 Feb 2012 23:24:32 +0000

Vielen Dank für den Beitrag! Ich habe mich heute zum erstem Mal mit den Hash-Möglichkeiten unter Java auseindander gesetzt. Ich habe auch intensiv nach ‘einfachen’ Lösungen im Internet gesucht, da halt md5() oder sha() von php her sehr bequem sind. Es hat mich dann sehr überrascht, als ich nur Anleitungen zum ‘selber bauen’ gefunden habe, welche für mich weit über das Ziel hinaus geschossen hätten. Daher habe ich dann begonnen, alles selbst zu implementieren…
Es kann doch nicht sein, dass man bei einer so verbreiteten Sprache wie Java etwas so essentielles wie eine Hash-Prüfung selbst zusammen stellen muss. Glücklicherweise ist dem nicht so, man muss halt einfach das richtige in Google eingeben

Dein Beitrag ist auf jeden Fall das Erste, was ich zu dem Thema wirklich brauchen kann.

Vielen Dank!

Comment on Unit Tests: Searching under the Lamp Post by Andreas Leidig

Andreas Leidig — Sun, 05 Feb 2012 22:33:36 +0000

Definitely agree. It reminds me of http://lisacrispin.com/wordpress/category/agile-testing-quadrants/

Another good read concerning this topic is the GOOS book (http://www.growing-object-oriented-software.com/) They build their Unit Tests hierarchically using mocks for “dependents”. In my opinion this is /the/ structure for good unit tests.

This way you will cover only Q1 of the quadrants. The other quadrants need not be forgotten.

Comment on Tips for Testing Database Code by Sunil

Sunil — Sat, 04 Feb 2012 19:31:26 +0000

Very good topic, explained very clearly.thank you for good post.

Comment on Tips for Testing Database Code by Jens Schauder

Jens Schauder — Mon, 30 Jan 2012 12:05:57 +0000

@Harald I agree

@Yulya I choose the word ‘favor’ for a reason. There are reasons where PL/SQL or similar languages are the correct choice. Very large databases certainly might qualify.

I don’t agree with the approach to production data. Yes you need a database with production data (or comparably data) for testing performance and such. But that doesn’t mean every developer needs to use that kind of database all the time.

Anyway there are lots of great points in the comments and also from a discussion I had after doing a talk about this topic at OOP 2012 so I guess I have to do a follow up on the topic. Stay tuned

Comment on Tips for Testing Database Code by Harald M.

Harald M. — Mon, 30 Jan 2012 11:13:55 +0000

Jens asked: “@bushfoot
how do you deal with changes in your schema? I once worked with a similar approach, but we finally ditched it because it became just impossible to maintain the scripts for inserting data.”

Well, you build your database in a CI (continuous integration) environment. If it does not build, someone has to change the insert scripts.

For this to work, you must go one step further than Jens’s first item: “Give every developer her own database.” This must be “Give every developer the means to create her own database.”

By this, people changing the database schema and writing tests can work in an agile way.

Of course, there’s more to all this: You need to keep your schema trackable – so for each and every SQL statement, you need a unit test that checks whether they still run. It helps if you have DAO layer (that contains all SQL statements); and it helps very much if you have a schema comparison tool (we use Redgate) so taht you can check in a “schema snapshot” and then check later what your developers changed.

We run a multi-million LOC software with (currently) more than 250 installations – and yet we allow every developer to change any part of the database schema in every (even minor) release … so yes, all this “agility on the database” does indeed work

Harald M.

Comment on Tips for Testing Database Code by Yuliya

Yuliya — Mon, 30 Jan 2012 09:27:13 +0000

There are some points in this post I am disagree with. Please, keep in mind that my opinion is based on my personal experience, mostly with huge Oracle databases (banking and money transfers).
Having test-database for every developer is a good idea in theory, but it creates huge amount of extra work. All of those databases must be synchronized constantly and have to hold identical data. If a production database holds terabytes of data, so should every test-database otherwise testing is pointless. In performance critical applications solutions that work well on small amount of data generally perform terribly in the real world. So usually I saw the following installment – developers have their own copy of production database, so does the QA team and so on. These approach proved to work well.

Second point that I can’t agree with is a choice of language. Personally, if I had a choice of programming language I would certainly go with mentioned criterions “For which do you get the better IDE, Unit testing support, code analysis, code coverage and so on”. But it’s not my opinion that matters in the real world. When I had to deal with hundreds of database requests per second, that could not be cached in anyway and required direct communication with the data, the build-in language wins hands down over proper languages (PL/SQL in Oracle). Yes, it’s far from perfect, but it does its job better. Some modules of the application are working better with the proper languages, but when it comes to the data, the built-in language has no competitors.

Comment on Fixing the Singleton by Jens Schauder

Jens Schauder — Thu, 26 Jan 2012 08:26:48 +0000

You are correct. The interface (in the java sense) isn’t strictly necessary. In the generic sense of a contract which is independent of the implementation is necessary though.

I’m thinking that when you are referencing the implementation directly it is to tempting to access the instance directly instead of through dependency injection.

But I might be wrong about that.

Comment on Fixing the Singleton by Born

Born — Thu, 26 Jan 2012 06:44:24 +0000

Hm – i don’t see why wee need an interface here? Of course one should implement against interfaces, but personally I prefer having interfaces if I need them, i.e. if I have more then one interpretation of a type. If I have a class with typical functionality, I don’t need an interface for a better design. I would use “introduce interface” refactoring right at the time I have a second class doing well unter the same type. I don’t like those projects where you have all those interfaces around without any reason for them. These interfaces are mostly created because in early days some teacher told us to always use interfaces

Comment on Database Version Management … Again by Petr

Petr — Wed, 25 Jan 2012 15:19:12 +0000

The liquibase is quite good, but if you need something without “ridden with horrible XML”, try Flyway – http://code.google.com/p/flyway/

Comment on Testing Databases with JUnit and Hibernate Part 2: The Mother of All Things by Jens Schauder

Jens Schauder — Wed, 25 Jan 2012 13:13:49 +0000

I'm taking the name from Fowler: http://martinfowler.com/bliki/ObjectMother.html And of course it reminds me of one of my favorite films: Alien. http://www.dailyscript.com/scripts/alien_shooting.html