Pipeline common tests

[daveter9]

Did a refactor which allows for dependency injection.

The PipelinePush and PipelinePull interfaces use PeerConnectionInformation to represent the config data required to set up a connection. The goal of these interfaces is to abstract away connection (ZMQ) specific behavior, since other connection implementations may require a different implementation of PeerConnectionInformation the current proposed refactor is not satisfying. How can this config be completely decoupled from the concrete connection Implementation?

[nickyu42]

From what i understand, the problem is that concrete implementations of PipelinePush and PipelinePull need their own config type to set up a connection, such as PipelinePullZMQ needing PeerConnectionInformation. Meaning that you want to completely remove the concrete config type from the PipelinePush and PipelinePull interfaces.

I think you could make it generic, if you really want to decouple it.

Example for PipelinePull:

PipelinePull.kt

// Add some constraints?
interface GenericConfig

interface PipelinePull<T : GenericConfig> {
    ...
    // Make config generic
    fun setupConnection(config: T)
    ...
}

AbstractPipelinePlugin.kt

data class PeerConnectionInformation(
    val host: String,
    val isBind: Boolean
) : GenericConfig

PipelinePull.kt

class PipelinePullZMQ : PipelinePull<PeerConnectionInformation> {
    
    // The type signature of the concrete class has the 
    // concrete implementation of the necessary config
    override fun setupConnection(config: PeerConnectionInformation) {
        when (config.isBind) {
            true -> socket.bind(config.host)
            false -> socket.connect(config.host)
        }
    }
    ...
}

[daveter9]

Achieved 50% Branch and 70% line coverage,
inline functions cannot be marked as covered by Jacoco (jacoco/jacoco#654)

[nickyu42]

I think ../pipeline/PipelinbePluginConfigurationTest.kt has a typo

[daveter9]

I think ../pipeline/PipelinbePluginConfigurationTest.kt has a typo

I will fix this

[nickyu42]

It seems you used colons (:Class:) to link classes and functions in your documentation, which doesn't automatically generate links i think.
From what I know, neither KDoc ([Class]) or JavaDoc ({@link Class}) use this convention.

Should we decide on a convention to use for documentation? I don't really mind really

[daveter9]

• Catch errors
• conflicting files

[molenzwiebel]

Renamer is included twice.