Project: Loans: You will be building a REPL file for the Loans project covered in a separate tutorial. This isn’t required but is a helpful way to better understand the smart contract used throughout this tutorial.

REPL stands for read - eval - print - loop. This acronym refers to the idea that given a Pact file, a REPL file is responsible for reading, evaluating, printing, and looping through the code as needed to both run and provide the output of the Pact file.

These are a common part of LISP-like languages such as Pact and they allow you to quickly test the smart contracts you build.

A simple way to load a REPL file is from your terminal as shown below.

Using your terminal window, you will load the REPL file. This includes code that both loads and runs the pact file. The pact file then returns data to the REPL file which sends the output to your terminal window.

To better grasp the importance of the REPL file, it helps to look at a tool you may be more familiar with - the online editor.

Many features provided by the online editor’s UI are things that you will need to code for yourself in a local or production environment. Things like loading the pact file into the REPL, setting up the environment data and keys, and making function calls will all be done from within the REPL file.

You will complete all of this and other important testing features using the Pact REPL only built-in functions.

For this code challenge, you will use env-keys and env-data to load the keys and environment data into the .repl file. Use the comments to help guide you, and if you’re unsure how to move forward, take a look at the solution for more details.

Before moving on, there’s an important note to make about transactions.

When working within REPL files, you can make as many calls to the pact code within a transaction as you like. Any command sent to the blockchain is a transaction, but a command too can have multiple calls, for instance, defining a module with module and creating its tables with create-table calls.

To successfully execute a transaction you need to both begin the transaction and commit the transaction. This is done using begin-tx and commit-tx.

It’s valuable to use these built-in functions to group calls into small transactions within your REPL file.

Here’s why this is useful.

Error Example

Any error that occurs in a transaction will cause it to roll back and fail to run.

While it's possible to place all of your calls within a single transaction, this isn’t a good habit to get into. This will make it difficult to tell where your file is failing and make it difficult to continue testing.

For that reason, be sure to break up your test files into smaller transactions.

(begin-tx);; This could fail and I would know where the problem is(commit-tx)(begin-tx);; This could fail and I would know where the problem is(commit-tx)(begin-tx);; This could fail and I would know where the problem is(commit-tx)

Transactions can be grouped together however is most convenient for your testing. Try maintaining a logical order in your transactions for ease of maintenance and readability.

Pact files are not run by your computer directly, they’re loaded into the .repl file and run from there. Now that you have loaded the environment data, you need to load the pact file into the .repl file.

After calling functions used to create, assign, and sell a loan, you can now read some of the data that you created. Similar to before, you will be calling functions from the loans.pact file. Feel free to reference the previous challenge for guidance.

Here is a brief overview of the functions you will call in this challenge.

At this point you have completed the REPL file. Congratulations! The last step is to run the file from your terminal to view the output.

To do this, open your terminal and navigate to the 3-finish directory from your project folder.

cd 3-finish

Run pact.

pact

Loan the loans.repl file

pact> (load "loans.repl")

You should see an output to your terminal similar to the data shown below. Notice the flags similar to those that you’ve seen throughout the challenges. This is to help you see where the code you wrote is corresponding to the output in the terminal.

Take some time now to view the output and see how it aligns with the code you wrote in the REPL file.

As you’ve seen, you can run REPL files from your terminal to test Pact code.

Another valuable feature in the SDK is that it actually runs these files for you without using the terminal. This helps you spot errors from directly within Atom. Two features that help you spot errors are the error highlighting and the error message.

Error Highlighting

Shows up as red dot on line that includes error. REPL files with errors in them will have a red squiggly line under the file name.

Error Message

Gives details about the error source.

These are both valuable ways to effectively test and debug your Pact code.

After making this change, the filename keysets.repl should now have a red squiggle under it and line 35 should have a red dot next to it. Both of these indicate that a test is failing within the REPL file.

To get more information, you can click the dot on line 35 and select the triangle to view the source of the error as shown below. Using this detailed information you can better test and debug the code from within your Pact smart contract.

Note

To understand exactly what is failing and why, it helps to look through both the .pact and .repl files for more information. Take some time now to study the keyset example files as well as a few other examples to practice testing code and debugging errors.

Congratulations on completing this introduction to Testing Pact Code in the SDK!

In this tutorial, you learned both the basics of testing in the SDK and how to build your own REPL file. This is a great start to begin testing the smart contracts you build locally. From here, you can experiment with changing the .repl or .pact files to see how this changes the output in your terminal.

Using this workflow, you can begin building and testing files however you would like.