The other day I was running some unit tests in an app using the Play! framework and I wanted to see how the data in the database looked like. Tests are run using a H2 memory database so accessing this was not as straightforward as I am used to since most configuration in Play! is done by convention (or magic, not sure which). So I did not know the connection string to the database nor the credentials used by the framework. After some googling I came across the information needed.
I have been working on a project based on the Play! framework lately (the old version, 1.2.4) and I came across a real headscratcher. My problem was I needed to delete a foreign constraint in a table but this constraint had no name (it was not given a name when it was created). Deleting a constraint with standard SQL requires a name so I had to do come up with something else for my evolution script. I was using MySQL in production and H2 in test so it was not an option to use some MySQL specific code unless it was compatible with H2.
Every now and then I need to copy a folder which is under source control. By copying the folder all source control information is copied along which needs to be removed afterwards. If the amount of folders is small this is done pretty easy manually but when we are talking larger amounts of folders doing it manually easily ends up pretty time consuming.
Recently I was writing some unit tests where I needed to access a database sequence for generation of unique numbers. The production environment uses Oracle while my unit tests use HQSLDB. The numbers from the sequence are extracted by ordinary SQL through Hibernate meaning that I could not rely on specifying the database dialect since the SQL is hardcoded. The code used for extracting the numbers (in Oracle) looked something like this
I recently started using Mockito as a mocking framework. Mockito makes heavy use of static imports which by default in Eclipse are not accessible through code completion. It is possible to use the Mockito methods by accessing them through their class by writing
Mockito.whenbut this would quickly clutter your code with a lot of Mockito references. Code completion has been around for ages so not having it feels like coding in Notepad or vi. Fortunately I have found out that it is actually possible and quite easy to configure Eclipse to add the static imports which is a great relief.
I finally decided to write my own ORM for the Android platform simply because I thought this was really needed. The only option I found was the Active Android framework which is not open source in any way. So I figured it was time to code my own framework. So here is Concrete! The framework is still very rudimentary to say the least but if I find the time I think it will work out pretty nicely. I have been influenced by Hibernate, the Active Record pattern and of course Active Android. In the current state it does not support relations (yikes!) but I am working on this so stay tuned.
I am a big fan of test-driven principles but have been on projects where running the full unit test suite would last 2-3 hours simply because writing to and reading from the database would slow everything down. This normally lead to optimizations such as only creating test data once having the unfortunate side effect of making unit tests dependent on each other (one unit test may change some data used in another unit test). It can also lead to random behavior making the test pass one time and then not the other simply because unit tests are not necessarily run in the same sequence every time.
So I decided to go solo and start my own company. Developing applications for the mobile platform have been on my radar for some years now and I finally decided it was time to try it out. The name of the company is Brisk Bee and so the name of this blog has changed to reflect this. I spent a lot of time trying to think of a catchy name and this was not my best effort but the best effort where the domain was still available (yes, I am looking at you Foul Owl!). Looking up brisk at dictionary.com reveals this information:
For some time I have struggled with test dependencies between modules in Maven. Imagine this situation:
Writing code quite often involves writing a lot of unit tests. If your tests cover isolated business logic (standard unit tests) writing tests is usually pretty easy. No big dependencies and very isolated testing. If you are writing tests involving database connections things can get a little more complex. The datasource in an application context is usually stored in JNDI so you need to initialize this yourself when writing tests. I use simple-jndi for this and this is how I do it.