Last updated: 2022-05-01

  1. Learn
  2. Documentation
  3. Advanced Settings

Advanced settings - backgrounds

The Advanced settings section is available in the General tab when a project or account has been upgraded to the Professional plan. In addition, further functionalities such as the Security tab and Controllers tab are unlocked.

Advanced settings available in the Professional plan

Advanced settings available in the Professional plan

Test setup

Using the Test setup option, high-level integration tests can be enabled for all controllers in the project. This will result in the following changes in the source code in addition to the required setup:

  • BaseIT class for centralized initialization of the tests
  • a test class with the contextLoads() method to ensure that the application context starts correctly
  • one test class per controller in the project

Depending on the selected database, Testcontainers will also be used in the BaseIT class to launch an image with the actual database during testing. In order for this to work, Docker must be available in the current environment.

Tests are generated for both custom and generated controllers. This includes a direct test of the endpoint expecting a valid response (e.g. updateOrder_success). If feasible, test cases are also added for validating correct responses when a field or entity is missing. If security has been enabled for the project, valid credentials are automatically provided via the BaseIT class. Also a test is added ensuring that invalid credentials will result in an UNAUTHORIZED response code.

The test data for testing the CRUD endpoints is loaded using SQL scripts. However if MongoDB is selected, the documents are loaded via source code instead. For this purpose, a class TestData provides methods to clear all documents (clearAll) and to create test documents (one method per entity).

More background on the testing approach can be found in this article.

Multi Module option

If the multi module option is activated, the project is initialized with a base and a web module. For this the build file is extended (Gradle) or divided (Maven). The base module contains most of the code, while the web module primarily serves a wrapping function: the final executable jar is created from this module and contains all other modules and libraries.

Generated project with multiple options

Generated project with multiple options

Additional modules - which can be added after the download, if desired - should therefore reference the base module api project(':car-parts-base') and be referenced by the web module. This way they can access the base classes and data model and will be contained in the final jar.

Package structure and MapStruct

When the package structure is changed to domain driven, the classes are grouped by their respective entities - e.g. a package car_part is created containing the service, controller, dto, etc. of this entity. Otherwise, the grouping is done according to technical criteria - with packages rest, service, repos, and so on containing all classes of the respective type.

When MapStruct is activated, the necessary setup is provided and the mappers are generated for entities with the REST option enabled. More background on MapStruct is available in this article.

Further features

A custom REST interface can be created in the Controllers Tab - a walkthrough is available here. With this the API of the new application can be reviewed in the team and is available together with the tests in the generated code.

Pagination is available for generated as well as custom controllers. When the REST API option is enabled for an entity, the additional option is visible right below in the Bootify Builder. For custom endpoints, Page can be selected directly as a response type. Backgrounds on the implementation are available here.

In the Security Tab Spring Security with JWT can be activated. The background to this is explained in this article.

See Pricing
or read quickstart