sweetest-framework / sweetest Goto Github PK

Problem

• Module testing configuration makes choices of the dependency management feature obscure
• Adds boilerplate, as it has to be referenced in each steps class

Solution

• Force test or steps to explicitly initialize the dependency on their own
• To resolve a dependency getAssignableTo is used, you can not have two dependencies of the same supertype separately; to mitigate that:
  • Dependency lookup needs to become concrete, which means, when you need a dependency, it's not enough to register a specific dependency
  • It needs to be explicitly pointed out that a dependency X can also be used if type Y is needed

• Modularization
  • extract core code
  • separate Mockito mock provider from core code
  • extract v1 API

Problem

Currently we have to override the configuration in order to supply it to the framework. That's fairly inconvenient:

override fun configure() = super.configure()
        .requireReal<AuthManager>()

It would be better to have something like this:

init {
    requireReal<AuthManager>()
}

• Depending on the steps class the implementer chooses, the dependency mode (mock or real) is set

• Get rid of global state
• Move type lookup for consumption and configuration closer together
• Extract data structure of dependency configuration and state from logic

• Use specific exception types
  • Adapt existing tests accordingly
• Tests for all error cases
• Condense exception messages so cause stack doesn't need to be read through anymore
• Streamline language and formatting (e.g. use of quotes and line breaks)
• Add links to readme and guidelines for further reference

Problem

• For Kotlin-only code we can't use sweetest

Research

• Do we also need to separate coroutines utilities?
• Is kotlin-reflect available in Kotlin multiplatform?
• Currently we hardcode sweetest with Cucumber and JUnit – can that stay that way?

Solution

• Abstract mock creation
• Make automatic mock creation optional
• Module implementing mock creation
• Introduce build variants for Kotlin-only and JVM

Problem

• TestContext needs to be referenced in each steps class

Solution

• Could be handled in background for non-Cucumber tests

Problem

In order to use dependency and steps functions we need to import them explicitly, as they are extension functions.

Solution

They should be direct parts of the base classes.