You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
turn little tests and experiments which involve multiple "nodes" into proper tests inside a lab
TESTING STRATEGY
pull real data from dat to have test data
submit it to substrate
to verify
TESTING
set up testing environment to spin up 1+ tests and run them
GOAL put our "specification" into code
STRATEGY:
use transaction-factory in substrate
use maybe tape to write node tests
write everything as "integration tests" from JS side
CURRENT PRACTICE:
you usually don't spin up an entire node to run tests,
just the parts of the node you need (storage, wasm executor, etc.)and then call into their apis
GOAL:
how to spawn 1+ datdot nodes
=> execute transactions in controleld way
=> check if everything went as expected
=> and is repeatable
have integration tests where we can spin up
multiple substrate nodes on different platforms and see if they
connect to each other and work in expected ways.
If people will install datdot on windows, linux, macosx
some maybe rip out the internals to run it on servers
and avoid the electron app
...and who knows if somebody makes it work on mobile OS's
GOAL:
so, having a way to spin up all those different OS in the cloud
and install datdot and connect and test to reproduce problems which might occur in practice later on
TEST SCENARIO 0
use forceRegistering to check basic logic
TEST SCENARIO 1
register seeders
register data
log usersStorage and datHosters
JOSHUAS REMARK:
just grepping the codebase for node_testing to see how it's being used
but there are some really good benchmarks and tests in node/executor
I think I'll adapt them for our module and just use that
just discovered they can give is the concrete block size info you wanted
JOSHUAS COMMENT: (NOVEMBER 13th)
there are some testing scaffolding and you can test runtime functions individually,
for example writing integration tests by calling RPC via rust,
but presetting state and simulating interactions is not super easy.
there are no network testing tools to easily writing some scenarios and executing a quick simulation like:
spawn a bunch of substrate nodes
pre-configure state
and then execute a fixed set of transactions to simulate what happens
to then run some assertions against the state after the state transition
The text was updated successfully, but these errors were encountered:
@todo
TESTING STRATEGY
TESTING
set up testing environment to spin up 1+ tests and run them
GOAL put our "specification" into code
STRATEGY:
transaction-factory
in substratetape
to write node testsCURRENT PRACTICE:
just the parts of the node you need (storage, wasm executor, etc.)and then call into their apis
GOAL:
have integration tests where we can spin up
multiple substrate nodes on different platforms and see if they
connect to each other and work in expected ways.
If people will install datdot on windows, linux, macosx
some maybe rip out the internals to run it on servers
GOAL:
TEST SCENARIO 0
forceRegistering
to check basic logicTEST SCENARIO 1
usersStorage
anddatHosters
JOSHUAS REMARK:
just grepping the codebase for node_testing to see how it's being used
but there are some really good benchmarks and tests in node/executor
I think I'll adapt them for our module and just use that
just discovered they can give is the concrete block size info you wanted
JOSHUAS COMMENT: (NOVEMBER 13th)
there are some
testing scaffolding
and you can testruntime functions
individually,for example writing
integration tests
by callingRPC
via rust,but
presetting state
andsimulating interactions
is not super easy.network testing tools
to easilywriting some scenarios
andexecuting a quick simulation
like:spawn a bunch of substrate nodes
pre-configure state
execute a fixed set of transactions
to simulate what happensrun some assertions against the state after the state transition
The text was updated successfully, but these errors were encountered: