I am an avid test driven development (TDD) advocate nowadays, with a pragmatic slant of course, looking to bullet proof the features that I deliver to ensure that they do what is expected, and work out edge cases.
A big challenge to testing is generating of test data, which is needed to setup some integration test work flows. I have been using Jailer (http://jailer.sourceforge.net/) to generate data from existing tables in a Dbunit format which can then embed in my test dataset xml files.
This is a challenge due to the mapping of relationships by Jailer (a neat feature by the way). So while working Datagrip, the database IDE of choice, we were struck by how to export different formats when looking at a table. This solution would allow us to leverage available filtering and searching features, to nail down the datasets that needs to be exported.
On contacting the support team through Twitter (https://twitter.com/0xdbe/status/853900122828222465/photo/1), the recommendation was to modify the existing XML groovy script to generate DBunit XML, following the steps at https://www.jetbrains.com/help/datagrip/2017.1/extending-the-datagrip-functionality.html
And well an hour later below is a groovy script to do just that can be found at https://gist.github.com/ssmusoke/ca4c55b4e52de97acb99a590644a677f
The code was not being well rendered hence the move to a Gist
An interesting discussion that I had with my team mates over the last few days, whether we should create branches then merge later or keep working on the trunk within our Git based version control process. As the team is small, we are in the same premises but different locations, we agreed to move to work exclusively on the mainline for the following reasons:
- Reduce the amount of work having to remember which branches are active, so branches are an exception rather than the rule
- Adding practices like a CI pipeline (that’s additional work for all of us to setup) will provide a needed stability in the long-run as some of the projects are expected to be long running
- Working on the main line forces us to talk to each other, rather than IM away, so design decisions are shared across the team
- Branches discourage refactoring mostly due to the pain of merging refactored changes, and the fact that not everyone can benefit from the refactoring as soon as its completed – thanks to Twitter – Chris Ford
We used the following resources as research:
1. Martin Fowler – Feature Branch – http://martinfowler.com/bliki/FeatureBranch.html also talking about Feature Toggles – http://martinfowler.com/bliki/FeatureToggle.html
2. Apologists Defense of Trunk based development – http://www.tuesdaydeveloper.com/2015/05/an-apologists-defense-of-trunk-based-development/
3. What is Trunk Based Development http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
4. Shades of Trunk based development – http://paulhammant.com/2014/09/29/shades-of-trunk-based-development/
What do you use with your team and why?