ouroboros-consensus-diffusion-0.18.0.0: Integration for the Ouroboros Network layer
Safe HaskellSafe-Inferred
LanguageHaskell2010

Test.ThreadNet.General

Synopsis

Documentation

data PropGeneralArgs blk Source #

Constructors

PropGeneralArgs 

Fields

calcFinalIntersectionDepth ∷ ∀ blk. HasHeader blk ⇒ PropGeneralArgs blk → TestOutput blk → NumBlocks Source #

What was the most number of signed blocks needed to be dropped from a final chain in order to reach the final chains' common prefix?

NOTE: This count excludes EBBs.

prop_general ∷ ∀ blk. (Condense blk, Condense (HeaderHash blk), Eq blk, RunNode blk) ⇒ PropGeneralArgs blk → TestOutput blk → Property Source #

prop_general_semisync ∷ ∀ blk. (Condense blk, Condense (HeaderHash blk), Eq blk, RunNode blk) ⇒ PropGeneralArgs blk → TestOutput blk → Property Source #

Like prop_general but instead assuming semi-synchrony

For now, this simply disables a few Propertys that depend on synchrony.

prop_inSync ∷ ∀ blk. HasHeader blk ⇒ TestOutput blk → Property Source #

All final chains have the same block number

runTestNetwork ∷ ∀ blk. (RunNode blk, TxGen blk, TracingConstraints blk, HasCallStack) ⇒ TestConfigTestConfigB blk → (∀ m. IOLike m ⇒ TestConfigMB m blk) → TestOutput blk Source #

Thin wrapper around runThreadNetwork

TestConfig

data TestConfig Source #

Test configuration that does not depend on the block

The primary motivation for separating this type from TestConfigB and TestConfigMB is so that the instance Arbitrary TestConfig can be reused by multiple tests using different blks: as of yet, no block (each of which realizes a ledger-protocol combination) influences the validity of these data.

Constructors

TestConfig 

Fields

Instances

Instances details
Arbitrary TestConfig Source # 
Instance details

Defined in Test.ThreadNet.General

Show TestConfig Source # 
Instance details

Defined in Test.ThreadNet.General

data TestConfigB blk Source #

Test configuration that depends on the block (incl the ledger and/or protocol) but not on the monad

Some fields do not explicitly involve the blk type, but their semantics (at least their validity) does depend on the semantics of the underlying ledger and/or protocol. For example, nodeJoinPlan is here instead of in TestConfig because different blocks can withstand different degrees of absence/lateness. And epochSize is here because eg the Byron ledger assumes a fixed epoch size of 10k. And so on.

Instances

Instances details
(Show (TxGenExtra blk), Show (BlockNodeToNodeVersion blk)) ⇒ Show (TestConfigB blk) Source # 
Instance details

Defined in Test.ThreadNet.General

Methods

showsPrecIntTestConfigB blk → ShowS #

showTestConfigB blk → String #

showList ∷ [TestConfigB blk] → ShowS #

data TestConfigMB m blk Source #

Test configuration that depends on the block and the monad

The primary motivation for separating this type from TestConfigB is so that TestConfigB can occur in contexts (such as in PropGeneralArgs) for which the m parameter is irrelevant and hence unknown.

Constructors

TestConfigMB 

Fields

Expected CannotForge

Re-exports

data ForgeEbbEnv blk Source #

How to forge an EBB

Constructors

ForgeEbbEnv 

Fields

Instances

Instances details
Show (ForgeEbbEnv blk) Source # 
Instance details

Defined in Test.ThreadNet.Network

Methods

showsPrecIntForgeEbbEnv blk → ShowS #

showForgeEbbEnv blk → String #

showList ∷ [ForgeEbbEnv blk] → ShowS #