The idea for this lab is based on the professional scrum development training course and the agile code camp. Both events take place over the course of multiple days and additionally focus on agile processes. The professional scrum developer course even covers a few software craftsmanship topics. Shrinking the course duration from several days to a few hours sounds like magic. Unfortunately, we are no magicians (and we failed trying to be).

Goal

Originally it was planned to solely focus the technology lab on shiny new technologies like Neo4j, Riak and Node.JS. We shifted to development practices though as we figured that this is exactly what Berlin’s developer community needs: The start-up scene, of which there is a highly active one in Berlin, has little need for big data technologies. Sure, many of them are helpful, but would it not be more useful to help them ship awesome products and through this help them reach a state where they might actually need to cope with big data issues?

A plan was made: Avoid bureaucracy, avoid some of the overhead that typically comes with development methods (we should probably avoid our agile evangelists for the next few weeks after publishing this) and instead show them techniques and practices, that are cheap, easy to follow, and result in a higher software quality.

The Legendary movie database project was chosen for the lab. The domain is simple: You have movies and actors. Actors can play roles in movies. That’s it! The application would therefore support basic CRUD (create, read, update, delete) operations for movies. Attendees would add CRUD support for actors and work on some usability improvements.

In case you lost count: This is actually the fourth instalment of the movie database! There are also versions that implement ROCA, use AngularJS with requireJS and a mobile version with Sencha Touch.

Technology Stack

As far as the chosen technologies are concerned, we deviated from codecentric’s standard technology stack and chose one which attendees can easily dive into while leveraging existing knowledge. Specifically, we chose JavaScript as the main language. By doing so we were able to use the same language for server and client code. This led to the next technologies: Node.JS for the server side combined with express as a web framework and AngularJS for the front end. Data persistence was done using Neo4j. While not actually necessary, Neo4j is interesting and simple at the same time and therefore a good match for the technology lab.

We further integrated a fair share of testing libraries and frameworks. On the server side, the choice fell on the mocha framework, which is great for testing asynchronous code. For the unit tests, we mocked the Neo4j service using Sinon.JS. On the client side, we used Karma together with Jasmine for both unit-tests and end-to-end-tests.

You can check out the project on GitHub to see the whole technology stack. The project comes with a readme that explains all necessary steps for building, testing and running the application. Dependencies are properly declared in the package.json and can be looked up through the NPM registry.

Preparation

The timebox was the hardest challenge. The goal required every team to have a continuous integration and delivery infrastructure as well as local development environments and a version control system. To cope with this, we set up everything in advance:

• Six forks of the project on GitHub under six different users that were created just for this purpose. Attendees were organised in groups in the beginning of the technology lab and added to these projects as collaborators (which grants them commit permissions).
• The six repositories were connected to Travis-CI for continuous integration. Every commit would therefore result in an execution of a static source code analysis, unit and integration test execution as well as deployment to Heroku.
• Heroku was used as the target platform. Each team got his own Heroku app. The redeployment was triggered automatically by Travis-CI.

This resulted in a time frame of about 10 minutes from the push to GitHub until a finished deployment to Heroku. The best part: Attendees are not required to fiddle around with Travis-CI secure environments and Heroku configuration.

We prepared thumb drives with VirtualBox images for the attendees’ local development environments. The virtual box image contained everything necessary like an editor, a local database instance, all project dependencies, manuals and cheat sheets for the central frameworks and libraries and of course a fresh clone of the project’s repository.

Lab Outcome

As you might have expected, three hours were not enough time for this technology lab. In fact, the attendees just managed to get an overlook about the application’s sources and made a few modifications to the server and client side. Tests were not written by any of the participants, but questions were asked a lot about test execution and inner workings of the testing frameworks. Overall, the number of source files does not seem to have been a problem, but the number of libraries and their combination was too hard to grasp.

Agile practices suffered in the same way that tests suffered: While the interest in Travis-CI and Heroku was great and the simple configuration got much applause, the attendees had little use for continuous integration during the lab. It was simply not enough time to work independently on tasks and therefore to collaborate through the version control system and see the benefits of CI and CD. At least one agile practice got full attention: Pair programming was done throughout the three hours. Confronted with this bunch of new technologies, the attendees actively shared their insights and worked together by twos or threes on one machine.

On the other hand, preparation and setup went perfectly fine. Every attendee had VirtualBox installed and was able to import the virtual machine without any issues. The first participant to finish the setup was able to work on the code and commit something to their repository after 15 minutes. The decision to go without detailed setup instructions and instead rely completely on VirtualBox was proven right.

In the end, both, the attendees and we as coaches, were satisfied with the technology lab. The attendees further encouraged us to do the technology lab over the course of a full day as this would enable them to dive deeper into other interesting parts of the application like Neo4j and Karma (both of which the participants barely got in contact with). A full-day-course would also leave enough time, to not just learn about agile practices, but really use them. It is one thing to see how easy it is to configure Travis-CI and Heroku, but only by writing tests (and seeing the CI go red), that you can really appreciate it.

In addition to more time, code documentation combined with an architecture overview would surely help the participants. Most tasks were accompanied by hints, which proved to be very helpful for both teams. We need to evaluate how we further support the participants, without simply telling them the solution. Something which is not always easy.

We would love to do this technology lab again, either at a conference or as a separate event. We had a great time. The positive feedback and the great interest in the chosen practices and technologies confirmed that we are moving in the right direction. We hope to see you again next time, but then hopefully for more than just three hours .

Loops and Repeating Keywords

Let’s start with Loops. Those can come in quite handy at times and the Robot Framework is supporting them in quite some different flavours:

• Looping over a list of elements.
• Looping over a range of numbers.
• Repeating a single keyword several times.

The latter one is a bit different from the real loops as it means that all actions are really put into one Keyword (sometimes this might be meaningful and sometimes not). Furthermore it is not possible to exit (break) such a loop before all iterations have been finished.

Let’s take a look at some examples:

The Tests

*** Settings ***
Library           String

*** Test Cases ***
For-Loop-In-Range
    : FOR    ${INDEX}    IN RANGE    1    3
    \    Log    ${INDEX}
    \    ${RANDOM_STRING}=    Generate Random String    ${INDEX}
    \    Log    ${RANDOM_STRING}

For-Loop-Elements
    @{ITEMS}    Create List    Star Trek    Star Wars    Perry Rhodan
    :FOR    ${ELEMENT}    IN    @{ITEMS}
    \    Log    ${ELEMENT}
    \    ${ELEMENT}    Replace String    ${ELEMENT}    ${SPACE}    ${EMPTY}
    \    Log    ${ELEMENT}

For-Loop-Exiting
    @{ITEMS}    Create List    Good Element 1    Break On Me    Good Element 2
    :FOR    ${ELEMENT}    IN    @{ITEMS}
    \    Log    ${ELEMENT}
    \    Run Keyword If    '${ELEMENT}' == 'Break On Me'    Exit For Loop
    \    Log    Do more actions here ...

Repeat-Action
    Repeat Keyword    2    Log    Repeating this ...

The Output

Starting test: StandardLoopDemo.For-Loop-In-Range
20130426 11:24:14.389 :  INFO : 1
20130426 11:24:14.390 :  INFO : ${RANDOM_STRING} = B
20130426 11:24:14.390 :  INFO : B
20130426 11:24:14.391 :  INFO : 2
20130426 11:24:14.392 :  INFO : ${RANDOM_STRING} = ih
20130426 11:24:14.392 :  INFO : ih
Ending test:   StandardLoopDemo.For-Loop-In-Range

Starting test: StandardLoopDemo.For-Loop-Elements
20130426 11:24:14.394 :  INFO : @{ITEMS} = [ Star Trek | Star Wars | Perry Rhodan ]
20130426 11:24:14.395 :  INFO : Star Trek
20130426 11:24:14.396 :  INFO : ${ELEMENT} = StarTrek
20130426 11:24:14.396 :  INFO : StarTrek
20130426 11:24:14.397 :  INFO : Star Wars
20130426 11:24:14.398 :  INFO : ${ELEMENT} = StarWars
20130426 11:24:14.398 :  INFO : StarWars
20130426 11:24:14.399 :  INFO : Perry Rhodan
20130426 11:24:14.400 :  INFO : ${ELEMENT} = PerryRhodan
20130426 11:24:14.400 :  INFO : PerryRhodan
Ending test:   StandardLoopDemo.For-Loop-Elements

Starting test: StandardLoopDemo.For-Loop-Exiting
20130426 11:24:14.402 :  INFO : @{ITEMS} = [ Good Element 1 | Break On Me | Good Element 2 ]
20130426 11:24:14.402 :  INFO : Good Element 1
20130426 11:24:14.403 :  INFO : Do more actions here ...
20130426 11:24:14.404 :  INFO : Break On Me
Ending test:   StandardLoopDemo.For-Loop-Exiting

Starting test: StandardLoopDemo.Repeat-Action
20130426 11:24:14.408 :  INFO : Repeating keyword, round 1/2
20130426 11:24:14.408 :  INFO : Repeating this ...
20130426 11:24:14.408 :  INFO : Repeating keyword, round 2/2
20130426 11:24:14.409 :  INFO : Repeating this ...
Ending test:   StandardLoopDemo.Repeat-Action

Probably there is not too much to explain here as the syntax is pretty straight forward. One important thing to consider is that Keywords belonging to a loop-block have to be escaped as shown above using a “\”.

FAIL : FOR loop contains no keywords. – Not escaping the lines that belong to a certain loop will result in the before mentioned error message when executing the tests.

The above examples also already show some of the String Operations and features for Conditional Execution that are discussed in more detail in the following chapters.

Conditional Execution of Keywords

Conditional Execution of test code is something that can lead to quite some controversial discussions. No worries, I am not going to dig into those. The only thing that we should keep in mind is that the implementation of tests should be as simple and clear as possible. Adding a lot of conditions might contradict this approach.

In the following examples these related Keywords have been used:

• Run Keyword – This one is pretty cool as it allows to pass in a Keyword in a Variable. This makes it possible to create quite some dynamic to the tests as the Keyword to be executed could be returned from another keyword. Can be used to do either pretty neat things or to produce total chaos .
• Run Keyword If – This is very helpful when testing complex structures. This could be for example dynamic web pages that enable/disable certain fields based on some input data. When used properly it can be used to create if/else-like structures. But be careful: The more programming there is inside the tests the more difficult it is to do troubleshooting if tests are failing.
• Run Keyword And Ignore Error – Honestly I did not yet had any real-life usecase for this. It is just another example what is possible with the Robot Framework.

Looking into the documentation of the Build-In Library one can see that there are a lot more of those Keywords. Especially Keywords like “Run Keyword If Test Failed” can be very useful for troubleshooting by putting for example screenshots or other information to the Robot Log in case of failing testcases.

The Tests

*** Test Cases ***
Run-Keyword
    ${MY_KEYWORD}=    Set Variable    Log
    Run Keyword    ${MY_KEYWORD}    Test

Run-Keyword-If
    ${TYPE}=    Set Variable    V1
    Run Keyword If    '${TYPE}' == 'V1'    Log     Testing Variant 1
    Run Keyword If    '${TYPE}' == 'V2'    Log    Testing Variant 2
    Run Keyword If    '${TYPE}' == 'V3'    Log    Testing Variant 3

Run-Keyword-Ignore-Error
    @{CAPTAINS}    Create List    Picard    Kirk    Archer
    Run Keyword And Ignore Error    Should Be Empty    ${CAPTAINS}
    Log    Reached this point despite of error

The Output

Starting test: Robot Blog.StandardConditionDemo.Run-Keyword
20130426 13:34:50.840 :  INFO : ${MY_KEYWORD} = Log
20130426 13:34:50.841 :  INFO : Test
Ending test:   Robot Blog.StandardConditionDemo.Run-Keyword

Starting test: Robot Blog.StandardConditionDemo.Run-Keyword-If
20130426 13:34:50.843 :  INFO : ${TYPE} = V1
20130426 13:34:50.844 :  INFO : Testing Variant 1
Ending test:   Robot Blog.StandardConditionDemo.Run-Keyword-If

Starting test: Robot Blog.StandardConditionDemo.Run-Keyword-Ignore-Error
20130426 13:34:50.847 :  INFO : @{CAPTAINS} = [ Picard | Kirk | Archer ]
20130426 13:34:50.848 :  INFO : Length is 3
20130426 13:34:50.849 :  FAIL : '[u'Picard', u'Kirk', u'Archer']' should be empty
20130426 13:34:50.850 :  INFO : Reached this point despite of error
Ending test:   Robot Blog.StandardConditionDemo.Run-Keyword-Ignore-Error

Working with Strings and Lists

Well, basically there is a full programming interface – as used from higher level programming languages – available here. The following short example shows some very basic usage. It is probably a very good idea to browse the available keywords of the Collection Library and the String Library just to get an idea what functionality is available.

The Tests

*** Settings ***
Library           String
Library           Collections

*** Test Cases ***
StringsAndLists
    ${SOME_VALUE}=    Set Variable    "Test Value"
    Log    ${SOME_VALUE}
    @{WORDS}=    Split String    ${SOME_VALUE}    ${SPACE}
    ${FIRST}=    Get From List    ${WORDS}    0
    Log    ${FIRST}

The Output

Starting test: Robot Blog.StandardStringsAndListsDemo.StringsAndLists
20130506 21:21:05.880 :  INFO : ${SOME_VALUE} = "Test Value"
20130506 21:21:05.881 :  INFO : "Test Value"
20130506 21:21:05.882 :  INFO : @{WORDS} = [ "Test | Value" ]
20130506 21:21:05.882 :  INFO : ${FIRST} = "Test
20130506 21:21:05.883 :  INFO : "Test
Ending test:   Robot Blog.StandardStringsAndListsDemo.StringsAndLists

So far to get some ideas of the more basic functionality of the Robot Framework. At the time of writing this blog I was also trying out the latest version (in this case 1.1) of the Robot-IDE (RIDE). And I have to say it worked really well and tests could be executed right away from the IDE without any problems. Here are two screenshots to give some impressions.

Editing Testcases with RIDE

Executing Testcases from RIDE

You can download all examples from the following ZIP-file.

Part I: Robot Framework Tutorial – Overview
Part II: Robot Framework – A complete example
Part III: Robot Framework IDE
Part IV: How to Structure a Scalable And Maintainable Acceptance Test Suite
Part V: Robot Framework Tutorial – Writing Keyword Libraries in Java
Part VI: Robot Framework Tutorial – Loops, Conditional Execution and more

Business transactions

AppDynamics has the concept of business transactions that you monitor. Business transactions have an entry point, and everything that happens afterwards belongs to the transaction, in our case it’s a call graph of Java objects, some SQL communication with a database and optionally other resources that may be accessed.
There are different possibilities to define entry points for a transaction, one very common entry point is a Servlet for web applications. AppDynamics is able to autodetect different business transactions for different types of entry points.
For each business transaction type AppDynamics collects data depending on your configuration. In general it counts the number of calls and measures the time needed for it. If there are some calls that are very slow it starts a diagnostic session and records call graphs for the calls. And even without slow calls AppDynamics records a call graph here and there. You can even see the SQL statements made during the call.

A business transaction for Spring Batch

So, what is a good business transaction in batch processing? If our batch program is started by a web request, we could define this request as the entry point of our business transaction. Is that a good choice? A call would then span the whole batch job execution, and that’s a bad idea. Just think of the possible call graph, it would be really really big if AppDynamics wouldn’t cut it anyway. And we cannot compare performance if we just get one call per week (or how often your batch job runs).
A better choice is having the execution of a tasklet as a business transaction. Implementations of the interface org.springframework.batch.core.step.tasklet.Tasklet are responsible for processings inside a step. Its method execute is called as long as it returns RepeatStatus.CONTINUABLE, and each call is done in its own transaction. If you’re now asking yourself what the Tasklet has to do with your batch job, because you’re only using chunk based processing: There’s the implementation ChunkOrientedTasklet, which is used whenever you do chunk based processing, so even then the interface Tasklet is an adequate entry point for monitoring.
One more thing to think about: if we configure a business transaction for the interface Tasklet we cannot tell for which kind of batch job the tasklet was run. We need to find a way to distinguish between different jobs. And we will, as you can see in the next paragraph.

How to configure the business transaction

We will configure a POJO business transaction. Click Configure -> Instrumentation and select your application. If you’re not on the tab ‘Transaction Detection’, switch to it. Scroll down to ‘Custom Rules’ and hit the ‘+’ button to add a custom match rule.
Choose ‘POJO’ as the Entry Point type, then choose a name for the transaction. In the tab ‘Transaction Match Criteria’ choose ‘Match Classes that implements an Interface which Equals org.springframework.batch.core.step. tasklet.Tasklet‘. As ‘Method Name’ type in ‘execute‘.

If we would leave the transaction definition like that, we could not tell which call is for which job. We definitely want different transaction definitions for different jobs. We can accomplish this via ‘Transaction Splitting’, so switch to the tab with the same name. Check ‘Split POJO Transactions using one of the following mechanisms…’, then check ‘Use a method parameter to name Transactions’. The second parameter of the execute method is the ChunkContext, and if we call getStepContext().getJobName() on it, we get the job name, which would be a perfect discriminator for our business transaction. So we choose ’1′ as ‘Parameter Index’ and ‘getStepContext().getJobName()‘ as ‘Getter Chain to run on method parameter’.

Then click on the ‘Save’ button and restart the batch server.

An even better choice?

If you’re using Tasklet‘s execute method as the entry point to your business transaction, you don’t catch all processings that are done in one chunk. You are missing the update-methods of all ItemStreams, you are missing the updates on Spring Batch’s meta data tables, and you are missing the actual commit of the transaction. If that’s important for you, you can choose the following ‘Transaction Match Criteria’ in your POJO configuration:
‘Match Classes that extends a Super Class that Equals org.springframework.batch.core.scope. context.StepContextRepeatCallback‘.
‘Method Name Equals doInChunkContext‘.
Since the second parameter of the doInChunkContext method is the ChunkContext, the ‘Transaction Splitting’ settings can stay the same as above.

Conclusion

Monitoring Spring Batch with AppDynamics is a good way to keep an eye on the performance of your batch jobs. I described the instrumentation you need for monitoring Spring Batch jobs, try it out!

The following shows a kind of my personal top-5 list of problems that pop up quite regulary in the context of Test Automation for “bigger” (read non-trivial) projects. For sure there is no universally valid solution to those problems, but I nevertheless tried to give some ideas on how to tackle those from my personal experience. If you do not have – or finally overcome – these problems I would be very interested to read more on this in the comments section. The same is of course true for different or additional problems (and potential solutions).

Testdata – Preparing the database

Almost any application nowadays depends on some kind of database. And the automated tests rely heavily on the data in that database to produce repeatable results. Now what are some of the problems with setting up this data?

• Often one is depending on other systems and their database contents which is kind of “out of reach” to influence from within ones own project.
• There is – for different reasons – no dedicated database instance available that can be used exclusively for the automated tests. This can be quite annoying as manual usage might disturb the results of the automated tests and the automated tests might corrupt the data of “other users” of that system.
• Defining and/or finding a proper set of testdata can be difficult and sometimes requires sevaral iterations. Typically the need for testdata is growing together with the advancement in the development of the SuT.

Let’s not consider some more extreme scenarios where a legacy backend application might make use of some quite special database systems like IMS for example. That can make it really hard to initialize testdata from within a Test Framework or some CI-Environment.

The ideas!

The single most important thing to do here is probably communication (which by the way helps with a lot of problems ). Often people outside the project (sharing the environment) do not really know what we are doing and aiming for with the automated tests. This is especially important if there is no chance to get an own database instance for the CI-Environment, which is quite often the case. If a shared environment is used it might be possible to define a certain set of testdata that can then be exclusively used in the automated tests. Of course organisational solutions are never perfect, but that can work quite well.

The bigger problem might be setting up the testdata, especially when this can be invalidated by changes in other systems outside the project scope. Trying to find a perfect solution here might sometimes simply be impossible. If the potential changes to the external systems are not happening too frequently a reproducable approach in generating valid testdata might be a good choice. In a recent project we have done this by having reusable scripts to load new data to the system and export this into SQL-Scripts. Those can now be re-executed in the initialize phase of the test execution. Using the Robot Framework we have then created variables that contain the names/ids of that testdata. By using then only the variables in the actual tests it is possible to switch to a new testdata set without too many problems. (Of course this will work in a similar way also with other Test Frameworks.)

One idea that almost always shows up in the context of testdata creatin is using the own application for it. Often you anyway want to test creating new data sets using the application. Then way not use that data for further tests and in the end also test the deletion using the SuT? Well, it almost never works out. First of all it means that the SuT must be able to create all data that is required, which might be often enough the case. But then for testing with a lot of data the tests will become slow and potentially unstable. And even worth all tests will now depend on the tests creating the data. If those fail there is no chance to tell if any other part of the application is working or not. The tests deleting the data again might also fail leading to quite some dead data in the system that might be growing quickly as these tests are executed often.

Probably the bottom line here is that it is better to have a reproducable approach in creating testdata even if it means some re-work every now and then, than strifing for a perfect solution that might take really a lot of time and might still break in the end.

Web-Applications – Fighting with Selenium & Co.

A lot of Test Automation is done for modern web applications. And Selenium is the tool of choice quite often here. This is not bad in itself as the problems would be similar with other tools. Nevertheless Selenium is a kind of synonym for testing – and the corresponding problems – of web applications.

What are typical problems?

• Tests are not stable and show different results without any changes in the SuT.
• The SuT is based on web frameworks that are hard to test. Luckily I even forgot the name of a web framework that was changing id-values of HTML-elements every time a page was accessed.
• Typically the cool things (AJAX) are the ones that are hard to test.

What can be done?

Again this depends of course heavily on the project environment. Any new project development should have Test Automation in mind from the very beginning. Just do not make your life more complicated than it is anyway. Of course working in or expanding existing systems might not offer too many choices with respect to chosen technologies.

“Insanity: doing the same thing over and over again and expecting different results.” -Albert Einstein

One approach that is often missed is to minimize the amount of tests that make use of the GUI. Often we want to test the underlying services and even though it might seem to be more work to implement specific tests accessing the service-layer directly than reusing the GUI for this, it is often the much better solution in the long run. The tests are more stable this way and run a lot faster.

Of course there is always a need to test the application through its GUI as well. But if there are any prerequisites required for certain tests try to perform those not using the GUI (as mentioned above). Again this will minimize the amount of GUI operations using Selenium.

Finally one should of course evaluate new or different approaches for GUI tests if possible. Using the Robot Framework under Java it was for example long time not possible to switch to Selenium2Library as it was only working using Python. But luckily now there is a port available that supports the Java-side of the Robot Framework. This is just an example that shows that one should always keep an eye on the development of the Test Framework one is using. In early phases of a project availability of certain test functionality will for sure also affect the choice of the Test Framework.

CI-Server – Accessing the System

Your tests will run – and potentially fail – on the CI-environment most of the time. Having a CI-environment is of course an essential part of any test automation solution, but it also can have some stumbling blocks.

• Developers do not have proper access to the system to perform required configuration tasks. This can slow down the whole development to some extend.
• The system is shared among too many projects. This can be especially a problem with the server running the selenium-server. If the tests of one project go mad and is producing for example tons of open browser windows this will have negative impact on all other projects as well.
• There is no possibility to login to all parts of the system – potentially as admin – to perform for example certain tests steps manually to reproduce error situations that do not occur when testing locally.

Unfortunetly these are the kind of problems where often no too many things can be done. Depending on the size of the organisation these things might be simply hard to tackle. In case of problems try to get hold of some “system guy” who can help you accessing the system .

Complexity – Lost in Test Automation

The complexity of designing a good test automation suite is often highly underestimated. (This goes then also hand in hand with the next point about the project effort.) Writing the tests in a way that those are still maintainable once there are many of them is one challenge. The other challenge is making the tests as independent from changes in the SuT as they can possibly be.

The tool support for refactoring tests is also often not as good as for a programming language like Java for example. Bigger changes to the structure of the tests might be hard to implement of at least they will require a lot of effort. Therefore the “design-phase” of the test suite is really really important. The following blog post from my collegue Andreas shows one approach to reach this goal. Of course this has always to be adepted to ones own needs.

Another thing to look at is the amount vs. the quality of the tests. It is most often the goal to test important error situations and of course certain “good cases” as well. But is there really a need to have a lot of tests all testing more or less the same functionality in the same way? All these tests have to be maintained as the worth thing that can happen to any test automation is that failed tests are accepted as normal. Be realistic in the amount of tests that can be handled in the project. This will also speed up the overall test execution.

Test Automation – No additional project effort, please

Writing automated tests is effort. And it can even be a lot of effort. Most of the time this effort is very well spent and will pay back by increasing the project quality and saving time in the long run over the lifetime of the project. Nevertheless this is often underestimated and the bad thing that happens then is that it is tried to implement and maintain these tests kind of “by-the-way”. Sometimes this might work, but more often the project will end up with tests that do not run properly or are hard to maintain. Quite some projects might also need to build up competences in writing automated tests (using a certain tool), which again takes some time that must be planned as part of the project.

In an agile environment we should clearly come to the point where writing the automated tests is part of every sprint as it is part of the team’s Definition of Done. Trying to implement the tests at the end of the project is not only a thing that will never work out, but at the end a lot of advantages from having the tests every sprint is then not utilized.

- First Tip: Don’t debug too much!

Crazy statement to start a post about debugging. But it must be said! Try to split up your complex logic into many isolated units and write Unit-Tests to check the correct behaviour of your code. I see it very often, that people are clicking through large web-applications, filling out multiple forms, switching to different pages in the flow, just to check a calculation logic on the last page and after that implementing big parts of the logic in the debug view. Before starting your tomcat always ask yourself: Is there a way to check the behaviour with a unit test? But you can find tons of good material about good code design out there, from here I will focus on a few eclipse debugging tips, which you maybe don’t know or you have forgotten over the time.
 

- Breakpoint View : Conditional Breakpoints

Extreme useful if you are interested only in a special constellation of your application. For example if you want to see the 13th run in a loop or you are debugging functionality in an abstract super class and you only want to see one concrete implementation. You can setup the conditions in the breakpoint-view or with the contextmenu on the blue breakpoint-marker next to your code (“Breakpoint Properties”). You can choose to suspend when your code-snippet gets true or when the value of your snippet changes.
 


 

- Variables View: Show Logical Structure

If you want to see the values of a Map or a List in the variables view, it’s not always that easy with the default setting of eclipse. If you are using a HashMap for example, you have to click through the physical entries and you are confronted with implementation details of a HashMap. But there is a small button above the variables – “Show Logical Structure”. Very handy, especially if you don’t have meaningful toString()-methods for the objects in your structure. My boss showed me this feature a few weeks ago. You know, he is the guy who is working with PowerPoint or Excel the most time. What a shame for a developer like me
 

- Variables View: Change Value…

Instead of restarting your debug session with some slightly changed input data, let’s say entered in a web-form – you can also change the values of your variables directly during debugging. Sometimes you can safe some time and sometimes you can simulate some strange behaviour with that feature a bit easier.
 

 

- Display View

Do you know the “Display View”? You can activate it during debugging via “Window” -> “Show View” -> “Display”. Now there should be a blank new view in your Eclipse. You can use this view to enter and evaluate new code. The code is executed within the context of the current debugging positions, which means that you can use all your variables and even content assist. To execute your code, just mark it and use the context-menu or CTRL+U (execute) or CTRL+SHIFT+I (inspect).
 

 

- Navigation: Drop to Frame

I think everybody knows “Step Into”, “Step over” and maybe “Step return”. That are the basics to navigate through your code while you are debugging. I want to name 2 further ways to navigate, which I like very much. The first is “Drop to Frame”. With that feature you have the possibility to go back in time You can simply go to a point in your java stackframe where you have been before. It happens to me quite often, that I am debugging and then missing the point where I have to pay attention. With the “Drop to Frame”-Feature I can then run the code again very simple.
 

 

- Navigation: Step into Selection

The second one is “Step into Selection”. This is a pretty easy one, but not many people are using it. For that, you just have to press Ctrl+Alt and click on a method name, where you want to go. Very handy, very fast. Compared to the usual “Step Into” this is much better for example if you want to enter a method with many parameters and you one step trough all the parameter evaluations. “Run to line” is also a nice feature. Just place your cursor in front of the line where you want to stop and hit “CTRL+R”.
 

 

- Navigation: Use your keyboard

You are faster, if you avoid to use the mouse. You should know at least the following Shortcuts:

• F5 – “Step Into”
• F6 – “Step Over”
• F7 – “Step Return”
• F8 – “Resume”
• Ctrl+Shift+B – “Toggle Breakpoint”
• Ctrl+Shift+I – “Inspect”

- Breakpoint View: Watchpoints

What the hell is changing this variable?! Sometimes it is usefull to create a watchpoint. Then the debugger stops, whenever the watched field is changed or just read – you can configure that. Just doubleclick on a field, then you can see the watchpoint in the Breakpoint View and edit the properties. You can even configure a hit count, means that the debugger only stops, when the entered hit count is reached. This also works for usual breakpoints.
 

 

- Human Readable Objects

The Variables View is using the toString-Method of your objects to display the value. Because of this it is very, very helpful
to provide good toString-implementations. The javadoc of the default-toString-implementation in java.lang.Object recommends the same:

* Returns a string representation of the object. In general, the
* <code>toString</code> method returns a string that
* "textually represents" this object. The result should
* be a concise but informative representation that is easy for a
* person to read.
* It is recommended that all subclasses override this method.
[...]

You can have a look at the ToStringBuilder in commons-lang. It provides some functionality to write – quote from the javadoc – “good and consistent” toString-methods.

Typical situation: you are working on the project’s main development branch, but you now wish to review a colleague’s new feature, which has been developed in a feature branch. You switch to the feature branch, start the server, open the application and BAM, an exception occurs due a failed schema validation. The reason: your colleague made some schema changes in the feature branch that you forgot to apply.

Improving your Liquibase and HSQL workflow is rather simple: restart the database whenever the schema changes and apply the migrations! This is how you can do it in bash (sorry Windows users).

#!/bin/bash
set -e
 
HSQL_PID=""
PROJECT=""
 
if [[ $1 = "customisation" ]]; then
    echo "Using customer specific changelogs..."
    PROJECT="$PROJECT_REPO/customisation"
else
    echo "Using default changelogs..."
    PROJECT="$PROJECT_REPO/database"
fi
 
control_c() {
    kill $HSQL_PID
    exit
}
trap control_c SIGHUP SIGINT SIGTERM 0
 
start() {
    # Start HSQL
    java -cp "$M2_REPO/org/hsqldb/hsqldb/2.2.9/hsqldb-2.2.9.jar" \
         org.hsqldb.Server \
         -database.0 mem:myDB \
         -dbname.0 myDB &
    HSQL_PID=$!
 
    # Schema update
    mvn -f "$PROJECT/pom.xml" liquibase:update -Plocal --no-snapshot-updates
}
 
start
 
while true; do
    if hash inotifywait 2>/dev/null; then
        WATCH_DIR="$PROJECT/src/changelogs"
        echo "Watching $WATCH_DIR for changes..."
 
        # Wait for changelog changes
        inotifywait --recursive $WATCH_DIR \
                    --event modify \
                    --event move \
                    --event create \
                    --event delete
 
        # Just a precaution: wait until the VCS is done changing the branch
        sleep 1
    else
        echo "[Press any key to discard the schema and apply a new one...]"
        read
    fi
 
    # kill HSQL and wait until it is actually shut down
    kill $HSQL_PID
    while kill -0 "$HSQL_PID"; do
        sleep 0.1
    done
 
    start
done

You need to make sure that you have two environment variables setup. There should be a variable PROJECT_REPO which points to the root directory of your project’s repository and M2_REPO which points to the Maven repository. You may also need to tweak a few paths, e.g. the version of HSQL that you are using as well as the Maven project and profile names. At last, you should install the inotify-tools (unfortunately not available on OS X). inotifywait (part of the inotify-tools) is used to watch the changelog directory for changes. The project’s Wiki has a section on installation.

Once setup, usage is pretty easy: start the script and let it do the rest. When the inotify-tools are not installed, you need to switch to your terminal and hit “the any key” in order to discard the current and apply a new schema.