uKnit

I love unit tests but hate the process of writing them. Every Java developer knows the dull routine: look at the code in the source editor, toggle to the test code editor, create or copy variables, initialize, write assertions, and repeat the mind-numbing chore hundreds of times more. To complete a single test case, you have to toggle dozens of times and make equal or even more cuts and pastes. Real pain, and what a waste of time!

To ease the process, uKnit generates unit tests from the Java classes. It reduces the typing by more than 80 to 90%, and the developer just has to step in and fine-tune the final test.

Features

uKnit is quite powerful and generates tests for complex Java classes. Some of the highlights are

  • Easy to install and use; tested in Eclipse and Idea IDE.
  • Defines, initializes the variables, constructs when, then, and verify statements.
  • Generates separate test for each and every control flow path with test coverage greater than 90%.
  • Variable names are closely tied to source code for easy comparison between source and test code.
  • Use of a mock or real object for a type is user-defined.
  • Handles nested method calls such as private or super methods.
  • Supports lambda and method reference constructs.

Downsides

While uKnit handles complex programs very well, there are still many shortfalls. Some of the major ones are

  • uKnit is tide to JUnit and Mockito, and there is no support for other unit test and mock frameworks, at least for now.
  • No IDE plugin to configure and run; the user has to provide the package and class in the config properties file to generate the unit test.
  • It can’t distinguish the control paths in nested methods such as private or superclass methods.
  • Best practice dictates that for the classes the project defines, use mocks, and for classes from the dependencies, use real objects. However, uKnit creates mocks for everything except for the types configured in the config file.
  • The tests generated by uKnit are tilted more towards mocks, and there is little support for tests without mocks.
  • No support for new feature of Java 11 and beyond, such as record, multi-line string, etc.
  • uKnit can’t evaluate expected runtime values, and variables are initialized with sensible defaults or non-evaluated code from the source class; the user has to step in and replace them with expected values.
  • The primary objective of uKnit is to reduce typing, but it doesn’t guarantee that a test is a proper one. The developer has to analyze the test generated and fix any deficiencies.

We plan to fix some of the deficiencies in the future, depending on how well developers accept uKnit.