> For the complete documentation index, see [llms.txt](https://docs.svrunit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.svrunit.com/use-cases/testing-your-frameworks.md).

# Testing your frameworks

SVRUnit can also be used to **test** your framework. 

Let's imagine you are building a PHP framework, that is published as a composer dependency, as well as a PHAR binary.

You would usually start it with one of these 2 commands:

```bash
# composer dependency
php vendor/bin/myapp xyz

# phar file
php myapp.phar xyz
```

SVRUnit helps you with 2 things.

1. You can create your custom "E2E" setups where you start your framework and **verify the expected output** using SVRUnit
2. You can use SVRUnit [placeholders](/configuration/configuration.md#placeholders) to test both, the **script** as well as the **PHAR file** with the same tests.

Let's get started.

Because SVRUnit allows you to install it with Composer, it is recommended to install it directly as dependency. You can of course also use the PHAR file for this.

```bash
composer require svrunit/svrunit
```

Now create a **XML configuration** file that specifies 2 test suites.

\
Both test suites use the same test directory, but use **different executable placeholders**.\
With this approach, we can then use a placeholder inside the real tests later, so that we either use the script version of our file, or the PHAR binary, when running the tests.

Please keep in mind, this is totally optional...you don't need to use placeholders.

```xml
<svrunit>  
  <testsuites>   
      
     <testsuite name="bin" executable="php bin/myapp">
         <directory>tests/svrunit/tests</directory>
     </testsuite>

     <testsuite name="phar" executable="php myapp.phar">
        <directory>tests/svrunit/tests</directory>
     </testsuite>
        
  </testsuites>
</svrunit>
```

Last but not least, we need the specification of our tests in the YAML file.

If you use placeholders for your executable, just use **(($EXEC))** instead of the real path to your executable. If not, just use your real path.

```yaml
commands:

  - name: "Test validate command"
    command: "(($EXEC)) validate"
    expected: "All translations are valid"
        
  ....
  ....
```

That's it!

You can now **manually** run your tests, or even use your **CI/CD pipeline** for this.

<pre class="language-bash"><code class="lang-bash"><strong>php vendor/bin/svrunit --configuration=myconfig.xml  
</strong></code></pre>

####


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.svrunit.com/use-cases/testing-your-frameworks.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.