zunit

Name: zunit
Author: AdamBien

40stars10forks

How to install zunit?

adambien/airails/zunit

$npx -y skills add AdamBien/airails --skill zunit

Installs into the current project.

Summary

Generate and run zunit tests for java-cli-app projects. Use when asked to create tests, write tests, add tests, or generate test files for a java-cli-app project. Triggers on "zunit", "write tests", "create tests", "add tests", "test this", "generate tests", or requests to test a

Files · 1

View on GitHub

SKILL.md

1	Generate and run zunit tests for a java-cli-app project using $ARGUMENTS. Apply all rules below strictly.
2
3	## What is zunit
4
5	zunit is a zero-dependency test runner. It discovers `*Test.java` source files and runs each directly via `java --source 25`. No compilation step, no JUnit, no framework.
6
7	## Test Convention
8
9	- Test files: name ends with `Test.java`, placed in `test/` directory
10	- Each test file is a self-contained Java source script with `void main()`
11	- Tests run via `java --source 25 --class-path <classpath>`
12	- Failure: any thrown exception or non-zero exit = failed
13	- Success: clean exit with code 0
14	- All test files run concurrently in separate JVMs
15
16	## Test File Structure
17
18	Every test file follows this pattern:
19
20	```java
21	void main() {
22	// arrange
23	var input = ...;
24
25	// act
26	var result = SomeClass.someMethod(input);
27
28	// assert
29	assert expected.equals(result) : "expected %s but got %s".formatted(expected, result);
30	}
31	```
32
33	## Assertion Style
34
35	- No assertion libraries — use the built-in `assert` statement; zunit runs every test with `-ea`
36	- Always attach a descriptive message including expected and actual values: `assert condition : message`
37	- One test file can contain multiple assertions — the first failure stops the file
38	- For testing exceptions, use try/catch and throw `AssertionError` explicitly:
39
40	```java
41	void main() {
42	try {
43	SomeClass.methodThatShouldFail(badInput);
44	throw new AssertionError("expected exception was not thrown");
45	} catch (IllegalArgumentException expected) {
46	// success
47	}
48	}
49	```
50
51	Caveat: `assert` only executes with assertions enabled. Running a test file directly requires the flag: `java -ea FooTest.java`.
52
53	## Test Discovery for java-cli-app Projects
54
55	### Directory Layout
56
57	```
58	project-root/
59	├── src/main/java/ # main source (compiled by zb)
60	├── test/ # zunit test sources
61	│ ├── SomethingTest.java
62	│ └── AnotherTest.java
63	├── zbo/app.jar # zb output (auto-detected as classpath)
64	└── .zb # zb config
65	```
66
67	### Classpath
68
69	zunit auto-detects `zbo/app.jar` as the classpath. Tests import main classes directly — zb packages everything into `app.jar`.
70
71	## How to Generate Tests
72
73	1. Read the main source code in `src/main/java/` to understand what to test
74	2. Create test files in `test/` directory — one test file per logical concern
75	3. Name test files descriptively: `ParserTest.java`, `ValidationTest.java`, `OutputTest.java`
76	4. Test public behavior, not internal implementation
77	5. Include both happy path and error/edge cases
78	6. Keep each test file focused — prefer multiple small test files over one large file (they run concurrently)
79
80	## Test File Rules
81
82	- No package declaration
83	- No imports from `java.base` — it is automatically available
84	- Use module imports for non-base modules (e.g., `import module java.net.http;`)
85	- Use `var` for local variables
86	- Use unnamed class style — `void main()` at top level, helper methods as needed
87	- Do not use `IO.println()` for assertions — use `assert`
88	- Printing to stdout is fine for debugging but not required
89
90	## HTTP Client Timeouts
91
92	When tests make network calls using `java.net.http.HttpClient`, always set explicit timeouts to prevent tests from hanging:
93
94	- Set `.connectTimeout(Duration.ofSeconds(2))` on the `HttpClient`
95	- Set `.timeout(Duration.ofSeconds(2))` on each `HttpRequest`
96
97	## Running Tests
98
99	After generating test files:
100
101	1. Build first: `zb` (compiles main sources into `zbo/app.jar`)
102	2. Run tests: `zunit` (discovers `test/*Test.java`, runs against `zbo/app.jar`)
103	3. Alternatively: `zb && zunit`
104
105	Use `zunit -verbose` to debug classpath or discovery issues.
106
107	## Example
108
109	Given a main class in `src/main/java/Converter.java`:
110
111	```java
112	class Converter {
113	static int toFahrenheit(int celsius) {
114	return celsius * 9 / 5 + 32;
115	}
116	}
117	```
118
119	Generate `test/ConverterTest.java`:
120
121	```java
122	void main() {
123	// freezing point
124	var freezing = Converter.toFahrenheit(0);
125	assert freezing == 32 : "expected 32 but got " + freezing;
126
127	// boiling point
128	var boiling = Converter.toFahrenheit(100);
129	assert boiling == 212 : "expected 212 but got " + boiling;
130
131	// negative
132	var negative = Converter.toFahrenheit(-40);
133	assert negative == -40 : "expected -40 but got " + negative;
134	}
135	```

People who liked this also viewed

6 picks

Type

zunit

40stars10forks

View on GitHub

How to install zunit?

adambien/airails/zunit

$npx -y skills add AdamBien/airails --skill zunit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Generate and run zunit tests for a java-cli-app project using $ARGUMENTS. Apply all rules below strictly.
2
3	## What is zunit
4
5	zunit is a zero-dependency test runner. It discovers `*Test.java` source files and runs each directly via `java --source 25`. No compilation step, no JUnit, no framework.
6
7	## Test Convention
8
9	- Test files: name ends with `Test.java`, placed in `test/` directory
10	- Each test file is a self-contained Java source script with `void main()`
11	- Tests run via `java --source 25 --class-path <classpath>`
12	- Failure: any thrown exception or non-zero exit = failed
13	- Success: clean exit with code 0
14	- All test files run concurrently in separate JVMs
15
16	## Test File Structure
17
18	Every test file follows this pattern:
19
20	```java
21	void main() {
22	// arrange
23	var input = ...;
24
25	// act
26	var result = SomeClass.someMethod(input);
27
28	// assert
29	assert expected.equals(result) : "expected %s but got %s".formatted(expected, result);
30	}
31	```
32
33	## Assertion Style
34
35	- No assertion libraries — use the built-in `assert` statement; zunit runs every test with `-ea`
36	- Always attach a descriptive message including expected and actual values: `assert condition : message`
37	- One test file can contain multiple assertions — the first failure stops the file
38	- For testing exceptions, use try/catch and throw `AssertionError` explicitly:
39
40	```java
41	void main() {
42	try {
43	SomeClass.methodThatShouldFail(badInput);
44	throw new AssertionError("expected exception was not thrown");
45	} catch (IllegalArgumentException expected) {
46	// success
47	}
48	}
49	```
50
51	Caveat: `assert` only executes with assertions enabled. Running a test file directly requires the flag: `java -ea FooTest.java`.
52
53	## Test Discovery for java-cli-app Projects
54
55	### Directory Layout
56
57	```
58	project-root/
59	├── src/main/java/ # main source (compiled by zb)
60	├── test/ # zunit test sources
61	│ ├── SomethingTest.java
62	│ └── AnotherTest.java
63	├── zbo/app.jar # zb output (auto-detected as classpath)
64	└── .zb # zb config
65	```
66
67	### Classpath
68
69	zunit auto-detects `zbo/app.jar` as the classpath. Tests import main classes directly — zb packages everything into `app.jar`.
70
71	## How to Generate Tests
72
73	1. Read the main source code in `src/main/java/` to understand what to test
74	2. Create test files in `test/` directory — one test file per logical concern
75	3. Name test files descriptively: `ParserTest.java`, `ValidationTest.java`, `OutputTest.java`
76	4. Test public behavior, not internal implementation
77	5. Include both happy path and error/edge cases
78	6. Keep each test file focused — prefer multiple small test files over one large file (they run concurrently)
79
80	## Test File Rules
81
82	- No package declaration
83	- No imports from `java.base` — it is automatically available
84	- Use module imports for non-base modules (e.g., `import module java.net.http;`)
85	- Use `var` for local variables
86	- Use unnamed class style — `void main()` at top level, helper methods as needed
87	- Do not use `IO.println()` for assertions — use `assert`
88	- Printing to stdout is fine for debugging but not required
89
90	## HTTP Client Timeouts
91
92	When tests make network calls using `java.net.http.HttpClient`, always set explicit timeouts to prevent tests from hanging:
93
94	- Set `.connectTimeout(Duration.ofSeconds(2))` on the `HttpClient`
95	- Set `.timeout(Duration.ofSeconds(2))` on each `HttpRequest`
96
97	## Running Tests
98
99	After generating test files:
100
101	1. Build first: `zb` (compiles main sources into `zbo/app.jar`)
102	2. Run tests: `zunit` (discovers `test/*Test.java`, runs against `zbo/app.jar`)
103	3. Alternatively: `zb && zunit`
104
105	Use `zunit -verbose` to debug classpath or discovery issues.
106
107	## Example
108
109	Given a main class in `src/main/java/Converter.java`:
110
111	```java
112	class Converter {
113	static int toFahrenheit(int celsius) {
114	return celsius * 9 / 5 + 32;
115	}
116	}
117	```
118
119	Generate `test/ConverterTest.java`:
120
121	```java
122	void main() {
123	// freezing point
124	var freezing = Converter.toFahrenheit(0);
125	assert freezing == 32 : "expected 32 but got " + freezing;
126
127	// boiling point
128	var boiling = Converter.toFahrenheit(100);
129	assert boiling == 212 : "expected 212 but got " + boiling;
130
131	// negative
132	var negative = Converter.toFahrenheit(-40);
133	assert negative == -40 : "expected -40 but got " + negative;
134	}
135	```

People who liked this also viewed

6 picks

Type