hi @mariacarmina , just some clarification. We don't necessarily need to generate other keys on all tests.. we could also have the getSigner(0) and getSigner(1) (or even more) addresses and hard code them on some constants. The important is to have some keys/addresses for testing... and avoid stuff like:

provider = new JsonRpcProvider('http://127.0.0.1:8545')
await provider.getSigner(0)) // this kind of code does not work outside ganache, will will give 'NO ACCOUNT' error

We could do like:

provider = new JsonRpcProvider(rpc)
signer/wallet = new ethers.Wallet(SOME_KEY, provider)

thanks

From what we discussed today in the sprint planning session, this adds a bit of workload, because we do not want to expose the private keys clearly through the code. We leave it as low prio.

cc @alexcos20

what do you mean by expose private keys?? We are explicitly setting the PRIVATE_KEY env var in 90% of the test suite!
its a matter of using with new ethers.Wallet(SOME_KEY, provider) (better; use the blockchain class we have)
this instead provider.getSigner(0) does not work anywhere outside ganache
I also disagree it generates a lot of workload... it would probably take 1 hour at most

take the first integration test as example (we are exposing a key):

ENVIRONMENT_VARIABLES.PRIVATE_KEY,
'0xc594c6e5def4bab63ac29eed19a134c130388f74f019bc74b8f4389df2837a58',

provider = new JsonRpcProvider('http://127.0.0.1:8545')
publisherAccount = (await provider.getSigner(0)) as Signer

to:

const chain = new Blockchain('http://127.0.0.1:8545','development',8996)
provider = chain.getProvider()
publisherAccount = chain.getSigner()

i do agree its low priority but i think we might have misunderstood the main point here

I also disagree it generates a lot of workload

I meant for setup of the tests, not actually doing the modifications

what do you mean by expose private keys?? We are explicitly setting the PRIVATE_KEY env var in 90% of the test suite!

I see that on 4 test files we use setupEnvironment with explicitly private keys PRIVATE_KEY and also NODE_PRIVATE_KEY => my approach is to remove where private keys are exposed in the tests and also use blockchain class forgetting signers. certainly not 90%

actually is 7 not 4 :-) (counting integration tests only) but my point is mainly about the getSigner(0) ... setup & modification is not hard... anyway, not priority for now, for sure

I was counting the unit tests which were 4, there are 11 in total in tests. I understood the point and the effort on this should be as well low, will tackle when higher prio tasks are solved.
Here are 2 points that need to be solved:

• remove explicit PRIVATE KEYS from code
• replace getSigner(0) with blockchain class signer

I'll change the title accordingly.