Lets have a look at this in a little more detail and finish of with instructions on how to build and run LoadUI locally.
LoadUI uses JavaFX to provide its user-interface and makes heavy use of the included Controls, such as TextBoxes, Buttons, CheckBoxes, etc. Most of the graphical parts of LoadUI uses vector graphics to achieve the desired look, and as often as possible we use CSS to style these.
For layouting we use the existing Containers and different LayoutInfo properties together with XMigLayout.
An interesting problem we were faced with was integrating Groovy and JavaFX. LoadUI has a really cool component architecture which allows you to create your own custom components by writing Groovy scripts which automatically show up (and are updated!) inside LoadUI and act just as the standard component set (in fact, almost all the standard components were created in this way). The challenge here was how to specify the look of the component in groovy, which is then rendered by JavaFX. We solved this by basically using an MVC pattern where you write the Model for the component in Groovy and the JavaFX code renders the View; the DSL-possibilities in Groovy allowed us to create an extremely efficient syntax for building components and their behavior, making development of new components a breeze (of course custom components can be created with Java, but in most cases the simplicity of the groovy possibilities are preferable).
LoadUI uses OSGi at its core and consists of a quite a number of different bundles (all coded as Maven sub-modules in the source code). Many of these bundles are pure Java and together they make up the backend of the application. One of the bundles, loadui-api, holds a number of Java Interfaces exposing the functionality of LoadUI. Any frontend to LoadUI will mainly access the backend through the API, but also through the Service layer in OSGi. The JavaFX front end does just this; it is implemented as an OSGi bundle as well, and listens for the various Services that the API defines and which are provided by the other bundles. We use the Spring Dynamic Modules project, which provides IoC and manages exporting and importing OSGi Services, to simplify OSGi service usage and implementation.
As mentioned above it is easy to create custom components using the groovy-based component infrastructure, but if more elaborate components are required extending LoadUI via OSGi is just as possible; for example the soapUI-Runner component is a separate OSGi bundle that contains all its dependencies and functionality and exposes defined LoadUI services which will automatically be discovered and picked up the the LoadUI runtime.
LoadUI has its own testing framework for user interface testing, called TestFX. By combining AWT Robot with JavaFX's Node.lookup(), we can easily define tests that are actually simulating a user moving the mouse cursor and typing on the keyboard. Since there are several of these tests, and they take a few minutes to run, you might want to skip them sometimes; do this by using the Maven parameter -DskipTests.
5. Building LoadUI from source
Please see LoadUI's project page at Github.
6. Globally Created Files
loadUI saves all created files in a ".loadui" folder under the current users home directory;
- a workspace file will be created containing the projects and agents configured, together with workspace settings
- project files for each created project will be put here by default
- a keystore.jks file containing the default key used for encrypting traffic between the LoadUI application and configured LoadUI agents
- a .groovy folder which contains cached libraries used by groovy script components
- a controller-cache folder which contains cached OSGI bundles used by the LoadUI core
- a fileStorage folder used on agents for caching files used by distributed components
Hope that gets you started! Please don't hesitate to comment or ask questions on our LoadUI forum boards.