> For the complete documentation index, see [llms.txt](https://coldbox.ortusbooks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://coldbox.ortusbooks.com/the-basics/testing-quick-start/integration-testing.md).

# Integration Testing

Integration testing loads a virtual ColdBox application to test real requests with execute() and request().

## Integration Testing

We will begin our adventure with integration testing. Integration testing allows you to test a real life request to your application without using a browser. Your test bundle class will load a new virtual application for you to test each specification under it; all aspects of your application are loaded: caching, dependency injection, AOP, etc. Then you can target an event to test and verify its behavior accordingly. First of all, these type of tests go in your `integration` folder of your test harness or in the specific module folder if you are testing modules.

### Basics

![](https://content.gitbook.com/content/XMVfvHPJ9ZanT1mSFxLz/blobs/xQwe7QPyBVu6kHyrE7Hd/handlertotestrelationship.png)

Here are the basics to follow for integration testing:

* Create one test bundle class for each event handler you would like to test or base it off your BDD requirements
* Bundle class inherits from `coldbox.system.testing.BaseTestCase`
* The bundle class can have some annotations that tell the testing framework to what ColdBox application to connect to and test
* Execution of the event is done via the `execute()` method, which returns a request context object
* Execution of API requests can be done via the convenience `request()` method or the HTTP method aliases: `get(), post(), put(), patch(), head(), options()`
* Most verifications and assertions are done via the contents of the request context object (request collections)

```javascript


it( "can do a relocation", () => {
	var event = execute( event = "main.doSomething" );
	expect( event.getValue( "relocate_event", "" ) ).toBe( "main.index" );
} );

it( "can startup executable code", () => {
	var event = execute( "main.onAppInit" );
} );

it( "can handle exceptions", () => {
	// You need to create an exception bean first and place it on the request context FIRST as a setup.
	var exceptionBean = createMock( "coldbox.system.web.context.ExceptionBean" ).init(
		erroStruct   = structNew(),
		extramessage = "My unit test exception",
		extraInfo    = "Any extra info, simple or complex"
	);
	prepareMock( getRequestContext() ).setValue(
			name    = "exception",
			value   = exceptionBean,
			private = true
		)
		.$( "setHTTPHeader" );

	// TEST EVENT EXECUTION
	var event = execute( "main.onException" );
} );

describe( "Request Events", () => {
	it( "fires on start", () => {
		var event = execute( "main.onRequestStart" );
	} );

	it( "fires on end", () => {
		var event = execute( "main.onRequestEnd" );
	} );
} );

describe( "Session Events", () => {
	it( "fires on start", () => {
		var event = execute( "main.onSessionStart" );
	} );

	it( "fires on end", () => {
		// Place a fake session structure here, it mimics what the handler receives
		URL.sessionReference     = structNew();
		URL.applicationReference = structNew();
		var event                = execute( "main.onSessionEnd" );
	} );
} );

```

We will explain later the life-cycle methods and the `run()` method where you will be writing your specs.

> **Hint** Please refer to our BDD primer to start: <http://testbox.ortusbooks.com/content/primers/bdd/index.html>

### CommandBox Generation

Also remember that you can use CommandBox to generate integration tests with a few simple commands:

```
coldbox create integration-test handler=main actions=index,save,run --open
# help
coldbox create integration-test help
```

> **Info** Please also note that whenever you create a handler, interceptor or model with CommandBox it will automatically create the integration or unit test for you.

### Going Further: Real Browsers

Integration tests never run a browser: no HTML is parsed, no JavaScript runs and no cookies travel between requests. On BoxLang, [Browser Testing](/the-basics/testing-quick-start/browser-testing.md) adds the `@browser` annotation to a `BaseTestCase` spec, so it drives a real browser against your running application while keeping access to your routes and settings.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://coldbox.ortusbooks.com/the-basics/testing-quick-start/integration-testing.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
