You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: app/pages/6.0/19.testing/01.why-test/docs.md
+6-2Lines changed: 6 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,18 @@
1
1
---
2
2
title: Why Use Automated Testing?
3
3
description: Learn why testing is essential for building reliable, maintainable applications.
4
-
wip: true
5
4
---
6
5
7
6
Every developer has experienced this nightmare: You fix a bug in one part of your application, deploy it to production, and suddenly something else breaks. A "simple" change cascades into hours of debugging. Users report errors you never saw in development. You're afraid to modify code because you might break something.
8
7
9
8
**Automated testing** prevents this chaos. Tests are code that verifies your code works correctly. When you make changes, tests run automatically to catch bugs before they reach production. They act as a safety net, giving you confidence to refactor, add features, and fix bugs without fear. Good tests mean fewer production bugs, faster development, and better sleep at night.
10
9
11
-
UserFrosting includes PHPUnit for testing, and this chapter shows you how to write effective tests that make your application more reliable and maintainable.
10
+
UserFrosting provides comprehensive testing tools for both backend and frontend code:
description: How to execute your PHPUnit and Vitest tests, both locally and in CI/CD pipelines.
4
4
---
5
5
6
-
You can execute tests using [Phpunit](https://phpunit.de) directly :
6
+
UserFrosting provides two test suites: **PHPUnit** for backend PHP code and **Vitest** for frontend Vue/TypeScript code. Here's how to run both.
7
+
8
+
## Backend Tests (PHPUnit)
9
+
10
+
You can execute backend tests using [PHPUnit](https://phpunit.de) directly:
7
11
8
12
```bash
9
13
./vendor/bin/phpunit
10
14
```
11
15
16
+
Or use the predefined VS Code task:
17
+
18
+
- Open Command Palette (`Cmd+Shift+P` on macOS, `Ctrl+Shift+P` on Windows/Linux)
19
+
- Run `Tasks: Run Task`
20
+
- Select `Backend - PHPUnit`
21
+
12
22
UserFrosting's built-in integration tests use a temporary in-memory SQLite database. For testing to run successfully, you must have the `php-sqlite3` package installed and enabled. Alternatively, you can create a separate testing database and override the `test_integration` database settings in the `testing.php`[environment mode](/configuration/config-files) from your site sprinkle.
13
23
14
-
When testing, only the tests define in your Sprinkle will be run. UserFrosting base system tests are run in their own repository.
24
+
When testing, only the tests defined in your app will be run. UserFrosting base system tests (located in `/vendor`) are run in their own repository.
25
+
26
+
## Frontend Tests (Vitest)
27
+
28
+
Execute frontend tests using npm:
29
+
30
+
```bash
31
+
npm run test
32
+
```
33
+
34
+
Generate a coverage report:
35
+
36
+
```bash
37
+
npm run coverage
38
+
```
39
+
40
+
Or use the predefined VS Code task:
41
+
42
+
- Open Command Palette
43
+
- Run `Tasks: Run Task`
44
+
- Select `Frontend - Tests` or `Frontend - Coverage`
45
+
46
+
Coverage reports are typically generated in `_meta/coverage/` or `_meta/_coverage/` and can be viewed in your browser.
47
+
48
+
> [!TIP]
49
+
> During development, use watch mode (`npm run test:watch`) to get instant feedback as you write code. Vitest will automatically re-run affected tests when you save files.
50
+
51
+
## Continuous Integration
52
+
53
+
In CI/CD pipelines, run both test suites:
54
+
55
+
```bash
56
+
# Backend tests
57
+
./vendor/bin/phpunit
58
+
59
+
# Frontend tests
60
+
npm run test
61
+
62
+
# Optional: Generate coverage reports
63
+
npm run coverage
64
+
```
65
+
66
+
Many teams configure CI to fail the build if test coverage drops below a certain threshold.
Copy file name to clipboardExpand all lines: app/pages/6.0/19.testing/03.writing-tests/01.testcase/docs.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: Sprinkle Test Case
3
-
wip: true
3
+
description: Master the UserFrosting TestCase class with helper methods for testing routes, JSON responses, and HTTP requests.
4
4
---
5
5
6
6
To make it easier to run your tests in your Sprinkle environment, that is with every routes, middlewares and other class registered in your Recipe, UserFrosting provides a base TestCase you can use. You simply need to tell the TestCase to use your Recipe. It will create a simple UserFrosting app instance, and cleanly destroy it when the test is done. It also provides some additional helper methods.
@@ -10,7 +10,7 @@ To make it easier to run your tests in your Sprinkle environment, that is with e
10
10
11
11
## Integrating with your Sprinkle
12
12
13
-
To begin testing your Sprinkle, your test case simply need to extends`UserFrosting\Testing\TestCase`. Then, define your Sprinkle Recipe in the `$mainSprinkle` property. For example:
13
+
To begin testing your Sprinkle, your test case simply needs to extend`UserFrosting\Testing\TestCase`. Then, define your Sprinkle Recipe in the `$mainSprinkle` property. For example:
14
14
15
15
```php
16
16
<?php
@@ -31,9 +31,11 @@ class MyTest extends TestCase
31
31
}
32
32
```
33
33
34
-
You could also use the code above as a new test case, instead of defining `$mainSprinkle` in every tests. Instead of naming the class `MyTest`, name it `MyTestCase` and make every test class extend `MyTestCase`.
34
+
> [!TIP]
35
+
> You could also use the code above as a new test case, instead of defining `$mainSprinkle` in every tests. Instead of naming the class `MyTest`, name it `MyTestCase` and make every test class extend `MyTestCase`.
35
36
36
-
The biggest advantage is you don't *need* to use your Recipe. Alternatively, you can create a recipe stub. Simply create a *second* recipe in your testing directory. This other recipe can register only the class you want to test.
37
+
> [!TIP]
38
+
> You don't *need* to use **your** Recipe. Alternatively, you can create a recipe stub only for testing. Simply create a *second* recipe in your testing directory. This other recipe can register only the class you want to test.
37
39
38
40
## Helping methods & properties
39
41
@@ -48,11 +50,11 @@ When extending `UserFrosting\Testing\TestCase`, you have access to many helper m
48
50
|`$this->mainSprinkle`| The main sprinkle identifier |
49
51
50
52
> [!NOTE]
51
-
> The default PHPUnit `setUp` method will create the application, while `tearDown` will delete the application. All properties needs to be access after invoking the parent method.
53
+
> The default PHPUnit `setUp` method will create the application, while `tearDown` will delete the application. All properties need to be accessed after invoking the parent method.
52
54
53
55
### createRequest
54
56
55
-
This methods can be used to create a basic `ServerRequestInterface`.
57
+
This method can be used to create a basic `ServerRequestInterface`.
Copy file name to clipboardExpand all lines: app/pages/6.0/19.testing/03.writing-tests/02.Traits/docs.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: Helper Traits & Class
3
-
wip: true
3
+
description: Discover testing utilities like ContainerStub, BakeryTester, RefreshDatabase, and WithTestUser for easier test setup.
4
4
---
5
5
6
6
UserFrosting provides some helper Traits to easily enable features and tools for your tests. Some of those tools make it easier to test your code against a testing database.
By default all tests are run against an in-memory SQLite database. This database is temporary and independent from the database used by your UserFrosting instance. That means your data is safe when tests are run. If you prefer to use a real database for tests, you can overwrite the `test_integration` connection config in your own sprinkle for the `testing` environment.
74
74
75
75
> [!WARNING]
76
-
> While you **can** test your code against the main database, it usually not a good idea to do so with a production database. Those are _tests_ after all. They _can_ fail. **Catastrophically**. UserFrosting built-in tests are all run against a test database.
76
+
> While you **can** test your code against the main database, it's usually not a good idea to do so with a production database. Those are _tests_ after all. They _can_ fail. **Catastrophically**. UserFrosting built-in tests are all run against a test database.
77
77
78
78
Note that the in-memory database is empty by default. If your test requires the standard tables to be up, you need to use the `UserFrosting\Sprinkle\Core\Testing\RefreshDatabase` trait to run all migrations up. You could also use the migrator service to run a particular migration up.
79
79
@@ -98,14 +98,14 @@ class MyTest extends TestCase
98
98
}
99
99
```
100
100
101
-
It's good practice to reset your database before each test so that data from a previous test does not interfere with your tests. The `RefreshDatabase` trait will help you wipe the database clean and run all migration up.
101
+
It's good practice to reset your database before each test so that data from a previous test does not interfere with your tests. The `RefreshDatabase` trait will help you wipe the database clean and run all migrations up.
102
102
103
103
> [!WARNING]
104
104
> This is **destructive**! All existing data in the database will be lost. Use it along the in-memory SQLite database to avoid losing data in your production database
105
105
106
106
## WithTestUser
107
107
108
-
This trait contains many useful methods for tests that require an actual user. To use any of the methods, you first need to add the `UserFrosting\Sprinkle\Account\Testing\WithTestUser` trait to your class. This trait add a single public method, `actAsUser`:
108
+
This trait contains many useful methods for tests that require an actual user. To use any of the methods, you first need to add the `UserFrosting\Sprinkle\Account\Testing\WithTestUser` trait to your class. This trait adds a single method, `actAsUser`:
109
109
110
110
```php
111
111
protected function actAsUser(
@@ -116,7 +116,7 @@ protected function actAsUser(
116
116
)
117
117
```
118
118
119
-
The method accept a UserInterface class. Optionally, you can use the `$isMaster` to force the user to be a master user (useful to bypass any permission checks!), pass roles to assign to this user (as an array of `RoleInterface`), or permissions (as an array of `PermissionInterface` or permissions slugs).
119
+
The method accepts a UserInterface class. Optionally, you can use the `$isMaster` to force the user to be a master user (useful to bypass any permission checks!), pass roles to assign to this user (as an array of `RoleInterface`), or permissions (as an array of `PermissionInterface` or permissions slugs).
120
120
121
121
**Example: Create a user using Factories, and assign `test_permissions`**
0 commit comments