Skip to content
Automated user-interaction testing for TornadoFX
Branch: master
Clone or download
ahinchman1 Merge pull request #46 from tieskedh/getOrPut
Replaces manual get/put with getOrPut/getOrPutNullable
Latest commit 1ff495a Nov 2, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
gradle/wrapper reverted gradle properties to work with ZuluJDK8 May 29, 2019
src Merge pull request #46 from tieskedh/getOrPut Nov 2, 2019
.gitignore Gradle Kotlin DSL + Cleanup May 6, 2019
EditorTest.kt Added parsing support for negative numbers, reformatted test writing … May 4, 2019
Generative Testing.png added photos back Jan 12, 2019 More parser cleanup, added generic argument support for parent classe… May 18, 2019 minor cleanup Jun 2, 2019
TornadoFX-Suite-Phase-3.png minor cleanup Jun 2, 2019
function_composition_mapping.png minor cleanup Jun 2, 2019
gradlew Gradle Kotlin DSL + Cleanup May 6, 2019
gradlew.bat Gradle Kotlin DSL + Cleanup May 6, 2019
sample_AST_breakdown.txt fixed several bugs for the AST parser. Will need to figure out why th… Jan 7, 2019
settings.gradle.kts Gradle Kotlin DSL + Cleanup May 6, 2019
tornadofx-suite.png minor cleanup Jun 2, 2019

TornadoFX-Suite (Stage 2)

Automated UI test generation for TornadoFX. A study in Kotlin & Metaprogramming and how metaprogramming might be able to eventually further machine learning.

Note: For the time being, the scope of this project is kept small. A user should be able to input their TornadoFX project and have tests generated for inputs like textfields, checkboxes, buttons, and so on


Testing has always been a challenge for engineers - many of us are opiniated on how testing should affect our development process and what ought to be tested in applications. While we will do our best to update as we go both in our issues and on here, TornadoFX-Suite is a work in progress:


  • Stage 1: Locating UI Nodes Scanning and parsing uploaded code to locate UI Nodes and create a basic class breakdown.
  • Stage 2: Generating UI Tests finding ways for Kotlin to create code-that-creates-code
  • Stage 2: Abstract Compositional Contracting Post-parsing analysis to map associate functions to nodes and create functional composition for nodes. Creating a DSL to create an easy structure for writing tests. altext
  • Stage 3: Creating FINITE State Machines
  • Stage 4: TBD Data collection/analysis using machine-learning to learn what makes more useful testing rules

Interested in the project? It's open source and anyone is welcome to contribute! Feel free to head over to the Issues page to see what's going on.


Data Science Courses

Collaboration Standards

You'll notice some classifications for the way the issues are labeled. Ideally, every issue should be formatted a certain way. I just made this up. If you guys have something you like better let me know. You'll often see the issues necessary for this project to move forward in the format of


  • BUG

Where a category is just an arbitary set of concerns [FEATURE, BUG, INVESTIGATION] I made to address different kinds of issues as this project progresses.

And when it comes to naming branches to address these issues: bug_[bugNumber]/[name of bug] enhancement_[enhancement]/[name of enhancement] and so on.


Features are issues that are required to complete a stage.


I like to go with Yegor Bugayenko's definition, as quoted in his blog:

  • Lack of functionality. If a class (yegor256/cactoos#558) or the entire module (yegor256/cactoos#399) doesn’t provide the functionality you expect it to have, it’s a bug.

  • Lack of tests. If a class doesn’t have a unit test (yegor256/takes#43) or the existing test doesn’t cover some critical aspects of the class (yegor256/cactoos#375), it’s a bug.

  • Lack of documentation. If, say, a Javadoc block for a class does not clearly explain to you how to use the class, or the entire module is not documented well (yegor256/takes#790), it’s a bug.

  • Suboptimal implementation. If a piece of code doesn’t look good to you, and you think it can be refactored to look better, it’s a bug.

  • Design inconsistency. If the design doesn’t look logical to you (yegor256/cactoos#436) and you know how it can be improved, it’s a bug.

  • Naming is weird. If class, variable or package names don’t look consistent and obvious to you, and you know how they can be fixed ([yegor256/cactoos#274] (, it’s a bug.

  • Unstable test. If a unit test fails sporadically (yegor256/takes#506) or doesn’t work in some particular environment (yegor256/jpeek#151), it’s a bug.


Is there something down the road that might be relevant to later stages? Go ahead in put in a issue for discussion/invesigation.


Improve on a feature/functionality.

You can’t perform that action at this time.