> For the complete documentation index, see [llms.txt](https://boomi.markusschmidt.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boomi.markusschmidt.pro/boomi-scriptease/general.md).

# Concepts

There are **Tests** and there are Process- and Map-**Scripts**.

A script cannot run alone. It needs a *ScriptContext* which is normally provided during process execution by the Atom. The *ScriptContext* contains *document-, process- and execution properties*, as well as the *documents.*

{% hint style="info" %}
There is a **ProcessScriptContext** and a **MapScriptContext**, with slightly different content: a Map-Script does not have *Documents*. Instead, a MapScriptContext takes the input variables and provides the output variables after execution.
{% endhint %}

<figure><img src="/files/NMlyEcPDXfK0hRBRdDa5" alt=""><figcaption><p>Process Script Test and Script Context</p></figcaption></figure>

On the local test environment the Test acts as the host. The Test creates the [context](/boomi-scriptease/knowlede-base/script-contexts.md) that is passed into the script.

## The Test

A test class with on e or more test methods (`@Test test01()`) represents the host - a starting point where you create the *ScriptContext* (test execution environment) and where you can check if the script did what it was supposed to do: test assertions.

```groovy
class Test_HelloWorld {

    @SourceURI
    URI _sourceUri

    // Specify the Boomi Script that your want to test in this class.
    final MapScript _testScript = new MapScript("msgHelloWorld.groovy", _sourceUri)

    /** Your first Map Script Test. */
    @Test
    void test01() {
        //
        // A Map Script Test provides the mapping input parameters 
        // in the scriptContext, as they are defined in Boomi.
        // Script Output variables are also added to that context
        // and can be validated after the execution.
        //
        MapScriptContext scriptContext = new MapScriptContext(  [
                a: 5,
                b: 7
        ])
        _testScript.run(scriptContext)

        println("\r\n--- Test Output ----------")
        assert scriptContext.variables.total != null, "Script did not set 'total' as output parameter!"
        assert scriptContext.variables.total == (scriptContext.variables.a as int) + (scriptContext.variables.b as int), "Calculation result does not meet expectations!"

        // Print to console windows and validate results
        println("Test Total = " + scriptContext.variables.total)
    }
}

```

A single Test class can contain one or mare `@Test` methods. This makes sense if you want to Unit Test your scripts. I do normally start with one or two tests functions (incl. edge tests), to debug and test what I am developing. Over the time, when my script evolves and gets new functionality, I add new Tests. At the end of the day, you always want to run *all* tests successfully. The old ones, because you want to ensure the script's behaviours has not changed, and the new ones, to ensure the new functionality works properly.

## The Script

The script is what you copy & paste into Boomi, later. Let's check the *HelloWorld* Map Script.

```groovy
import com.boomi.execution.ExecutionUtil

final String SCRIPT_NAME = "msgHelloWorld"

final _logger = ExecutionUtil.getBaseLogger()
_logger.info('>>> Start Script ' + SCRIPT_NAME)

// This is the script's logic - not much - but anyways...
total = a + b

// Log the result and the end of the execution to process reporting
_logger.info("Total: " + total)
_logger.info('<<< End Script')
```