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
> Aside: Feel free to choose the amount of ada you want to fund your wallet with. Just remember: `addSomeWallet` takes a list of _lovelace_ amounts. Here, I've actually made my custom `Ada` type as well some helper utilities (not the same as `Plutus.V1.Ledger.Ada` as that is removed in newer `plutus-ledger-api` versions).
@@ -89,7 +92,7 @@ Once you have that, you can simply use `runContract` from `import Test.Plutip.In
1. Will start the local network with default config (more on configuring below)
21
21
2. Description of test group that will be run on current instance of the network
22
22
3. Test scenario that will be performed on the local network with it's description. Scenario includes:
23
-
1. (3.1.) Initialization of `wallets`. In this case two addresses will be funded: first will have 2 UTxOs with 100 and 200 Ada, second - single UTxO with 10 Ada.
24
-
2. (3.2) Execution of "`someContract :: Contract w s e a`". `PaymentPubKeyHash` of *first wallet* will be accessible in `someContract` as "own PaymentPubKeyHash". e.g with `ownFirstPaymentPubKeyHash`. `PaymentPubKeyHash` of *second* initiated wallet is brought into scope by `wallet2pkh` during pattern match on list (more on that below).
23
+
1. (3.1.) Initialization of `wallets`. In this case two addresses will be funded: first - enterprise address - will have 2 UTxOs with 100 and 200 Ada, second - base address - single UTxO with 10 Ada.
24
+
2. (3.2) Execution of "`someContract :: Contract w s e a`". `PaymentPubKeyHash` of *first wallet* will be accessible in `someContract` as "own PaymentPubKeyHash". e.g with `ownFirstPaymentPubKeyHash`. `PaymentPubKeyHash` of *second* initiated wallet is accessible through `wl :: WalletLookups` (more on that below).
25
25
3. (3.3) List of checks or `predicates` which will be performed for the result of `someContract` execution.
26
26
27
27
It is possible to run several scenarios on single network instance - note that `withConfiguredCluster` accepts list of `assertExecution`'s.
@@ -33,39 +33,61 @@ It is possible to initialize arbitrary number of `wallets` in second argument of
note that the lookup return type depends on a query tag. Unfortunetely the type hint is needed to avoid cryptic error message.
50
53
51
-
*`pkh1` is `PaymentPubKeyHash` of `wallet``initAda [200]`
52
-
*`pkh2` is `PaymentPubKeyHash` of `wallet``initAda [300]`
53
54
54
-
`PaymentPubKeyHash` of `wallet``initAda [100]` is meant to be `pkh0` and not presented in the list.
55
+
*`pkh1` is `PaymentPubKeyHash` of `wallet``initAda (PkhTag 1) [200]`
56
+
*`pkh2` is `PaymentPubKeyHash` of `wallet``initAda (BaseTag 2) [300]` and `spkh2` is its `StakePubKeyHash`
57
+
58
+
`PaymentPubKeyHash` of `wallet``initAda (PkhTag 0) [100]` is meant to be `pkh0` and not presented in the lookups.
59
+
60
+
61
+
You can execute a contract with base address as contracts address:
62
+
```haskell
63
+
(initAda (BaseTag0) [100])
64
+
```
65
+
66
+
and witness in contract
67
+
68
+
```haskell
69
+
withContract $\_ ->do
70
+
ourAddr :| _ <-Contract.ownAddresses
71
+
case addr of
72
+
Address (PubKeyCredential ourPkh) (Just (StakingHash (PubKeyCredential ourSpkh))) -> logInfo "This is the address we will get."
73
+
_ ->error"Nothing else matters"
74
+
```
75
+
76
+
Use `mustPayToPubKeyAddress` instead of `mustPayToPubKey` when your address has staking keys.
55
77
56
78
## Executing contracts
57
79
58
80
It is possible to run arbitrary number of contracts in 3d argument of `assertExecution` using its monadic nature. E.g.:
59
81
60
82
```haskell
61
83
assertExecution "Some description"
62
-
( initAda [100])
84
+
( initAda (PkhTag()) [100])
63
85
( do
64
86
void $
65
87
withContract $
66
-
\pkhs-> contract1
88
+
\wl-> contract1
67
89
withContractAs 1$
68
-
\pkhs-> contract2
90
+
\wl-> contract2
69
91
)
70
92
[shouldSucceed]
71
93
```
@@ -85,29 +107,29 @@ For example, consider the following scenario:
85
107
86
108
```haskell
87
109
assertExecution "Some description"
88
-
( initAda [100] -- walletA
89
-
<> initAda [200] -- walletB
90
-
<> initAda [300] -- walletC
110
+
( initAda (PkhTag'a') [100] -- walletA
111
+
<> initAda (PkhTag'b') [200] -- walletB
112
+
<> initAda (PkhTag'c') [300] -- walletC
91
113
)
92
114
( do
93
115
void $
94
-
withContractAs 1$-- running contract with walletB
95
-
\[walletA_PKH, walletC_PKH] -> setupContract1
116
+
withContractAs 'b'$-- running contract with walletB
117
+
\wl ->do
118
+
wallA <- lookupWallet wl (PkhTag'a')
119
+
setupContract1
96
120
void $
97
-
withContractAs 2$-- running contract with walletC
98
-
\[walletA_PKH, walletB_PKH] -> setupContract2
99
-
withContract $
100
-
\pkhs -> theContract
121
+
withContractAs 'c'$-- running contract with walletC
122
+
\wl ->do
123
+
wallB <- lookupWallet wl (PkhTag'b')
124
+
setupContract2
125
+
withContract $-- uses first wallet, walletA
126
+
\wl -> theContract
101
127
)
102
128
[shouldSucceed]
103
129
```
104
130
105
-
Under the hood, test runner builds list of wallets like this `[walletA, walletB, walletC]` and by calling `withContractAs` we can refer to an index (0 based) of specific wallet in this list. In that case, `PaymentPubKeyHash` of referenced `wallet` becomes "own" `PaymentPubKeyHash` of the contract, and `PaymentPubKeyHash`'es in argument of lambda will be rearranged. E.g. in case of `withContractAs 1`:
106
-
107
-
*`PaymentPubKeyHash` of `walletB` will become own `PaymentPubKeyHash`
108
-
* argument of lambada will contain `PaymentPubKeyHash`'es of `walletA` and `walletC`.
109
-
110
-
Actually, `withContract` is just shortcut for `withContractAs 0`.
131
+
`withContractAs` asks explicitly for the name of a wallet to be used as contract's.
132
+
Instead `withContract` uses the first wallet, first in the order of how the initializations are written.
0 commit comments