docs/versioned_docs/version-0.17.2/ci/quickstart/test.mdx
import Tabs from "@theme/Tabs"; import TabItem from "@theme/TabItem";
The test stage of the pipeline runs the application's unit tests and depends on the build-env stage. Let's look at its Dagger Function next.
This Dagger Function works merely as a CLI wrapper. It starts with the Container result of the previous Dagger Function, executes the npm run test:unit run command in the container, and captures and returns the output as a string (refer to the code comments for details).
Call the Dagger Function:
<Tabs groupId="shell"> <TabItem value="System shell"> ```shell dagger -c test ``` </TabItem> <TabItem value="Dagger Shell"> ```shell title="First type 'dagger' for interactive mode." test ``` </TabItem> </Tabs>Here's what you should see:
:::tip SANDBOXING All the Dagger Functions in this quickstart receive the location of the source code directory as a function argument, rather than reading it directly from the host filesystem. This is by design: Dagger Functions are fully "sandboxed" and do not have direct access to the host system. Therefore, host resources such as directories, files, environment variables, network services and so on must be explicitly passed to Dagger Functions as arguments. This "sandboxing" of Dagger Functions improves security, ensures reproducibility, and assists caching. :::