### Initializing ReVoman Configuration in Java

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This snippet demonstrates the basic invocation of the `ReVoman.revUp()` method to start a template-driven test. It shows how to pass a configuration object, built using `Kick.configure()`, which would include Postman templates, environments, and other customizations.

```Java
final var rundown =
	ReVoman.revUp(
		Kick.configure()
		...
		.off())
```

--------------------------------

### Installing an npm Module (moment) via Shell Script

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This shell command demonstrates how to install the `moment` npm package. This is a prerequisite step for using `moment` or any other npm module within ReṼoman's JavaScript pre-request and post-response scripts, allowing for extended functionality.

```shellscript
npm install moment
```

--------------------------------

### Installing JDK 17 with SDKMAN (Bash)

Source: https://github.com/salesforce-misc/revoman/blob/master/CONTRIBUTING.adoc

This Bash command installs a specific version of the Java Development Kit (JDK 17.0.14-amzn) using SDKMAN. It is a crucial prerequisite for compiling and running the Revoman project, ensuring the correct Java environment is in place.

```bash
sdk install java 17.0.14-amzn
```

--------------------------------

### Building Revoman Project with Gradle Wrapper (Bash)

Source: https://github.com/salesforce-misc/revoman/blob/master/CONTRIBUTING.adoc

This Bash command executes the Gradle wrapper to clean the project's build directory and then compile and package the application. It simplifies the build process by eliminating the need for a local Gradle installation, making it accessible for all contributors.

```bash
./gradlew clean build
```

--------------------------------

### Using npm Modules in Postman Pre-req/Post-res Scripts (JavaScript)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This JavaScript snippet illustrates how to import and utilize installed npm modules like `moment` and `lodash` within Postman's pre-request and post-response scripts, executed by ReṼoman. It shows examples of dynamically setting Postman environment variables for dates and random numbers.

```javascript
var moment = require("moment")
var _ = require('lodash')

pm.environment.set("$currentDate", moment().format(("YYYY-MM-DD")))
var futureDateTime = moment().add(365, 'days')
pm.environment.set('$randomFutureDate', futureDateTime.format('YYYY-MM-DD'))

pm.environment.set("$quantity", _.random(1, 10))
```

--------------------------------

### Defining a Custom Pre-Transaction Step Pick Hook in Java

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This snippet illustrates how to define a custom `PreTxnStepPick` predicate in Java. This predicate is utilized to qualify a step for a Pre-Step Hook, enabling the execution of custom JVM code before a step. The example demonstrates logging information about the `currentStep` prior to its execution.

```Java
final var preTxnStepPick = (currentStep, requestInfo, rundown) -> LOGGER.info("Picked `preLogHook` before stepName: {}", currentStep)
```

--------------------------------

### Automating Postman Collection with ReVoman in JUnit (Java)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This JUnit test example demonstrates how to automate a Postman collection using ReVoman. It configures `ReVoman.revUp()` with paths to a Postman collection template and environment, then asserts that no unsuccessful steps occurred and verifies the total number of step reports.

```Java
@Test
@DisplayName("restful-api.dev")
void restfulApiDev() {
	final var rundown =
		ReVoman.revUp( // <1>
			Kick.configure()
					.templatePath(PM_COLLECTION_PATH) // <2>
					.environmentPath(PM_ENVIRONMENT_PATH) // <3>
					.off());
	assertThat(rundown.firstUnIgnoredUnsuccessfulStepReport()).isNull(); // <4>
	assertThat(rundown.stepReports).hasSize(4); // <5>
}
```

--------------------------------

### Applying Code Formatting with Spotless (Bash)

Source: https://github.com/salesforce-misc/revoman/blob/master/CONTRIBUTING.adoc

This Bash command runs the Spotless Gradle plugin to automatically apply code formatting rules across the entire codebase. It ensures consistent code style, reduces merge conflicts, and should be executed before committing changes to maintain code quality.

```bash
./gradlew spotlessApply
```

--------------------------------

### Configuring Pre and Post Hooks in ReṼoman (Java)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This Java configuration snippet demonstrates how to add `pre` and `post` hooks to a ReṼoman test run. It shows how to integrate predefined hook variables (like `preTxnStepPick` and `postTxnStepPick`) alongside inline lambda expressions for custom logic execution before and after each step.

```java
.hooks(
	pre(
			preTxnStepPick,
			(currentStepName, requestInfo, rundown) -> {
				//...code...
			}),
	post(
			postTxnStepPick,
			(currentStepName, rundown) -> {
				//...code...
			})
)
```

--------------------------------

### Accumulating Configurations in Revoman (Java)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This snippet illustrates how to construct a new `Revoman` configuration instance by accumulating attributes from multiple existing configuration instances using the `from()` method. This allows for combining different sets of configuration attributes into a single, new immutable configuration. It's important to note that for iterable attributes, the order depends on the `Iterable` instance passed.

```Java
Kick.configure().from(configInstance1).from(configInstance2)...off();
```

--------------------------------

### Publishing Revoman to Sonatype Nexus (Bash)

Source: https://github.com/salesforce-misc/revoman/blob/master/CONTRIBUTING.adoc

This Bash command publishes the Revoman project artifacts to Sonatype Nexus, then closes and releases the staging repository to Maven Central. The flags -Dorg.gradle.parallel=false and --no-configuration-cache are used to ensure a stable publishing process, typically for manual releases.

```bash
./gradlew publishToSonatype closeAndReleaseSonatypeStagingRepository -Dorg.gradle.parallel=false --no-configuration-cache
```

--------------------------------

### Configuring ReVoman for End-to-End Testing in Java

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This Java code demonstrates an advanced configuration of ReVoman for end-to-end testing. It initializes `ReVoman` using `revUp()` with a `Kick.configure()` builder, specifying template and environment paths, and dynamic runtime variables. It includes a custom dynamic variable generator for `$unitPrice`, sets a Node.js modules path, and defines execution control to halt on HTTP status failures except for specific cases. The configuration also sets up request and response unmarshalling for specific URIs and POJO types, along with pre-step and post-step hooks for custom logic like logging, response validation, and asynchronous processing waits. Finally, it adds a global custom type adapter and enables insecure HTTP for local testing, followed by assertions on the `Rundown` object and its mutable environment.

```Java
final var pqRundown =
	ReVoman.revUp( // <1>
			Kick.configure()
					.templatePaths(PQ_TEMPLATE_PATHS) // <2>
					.environmentPath(PQ_ENV_PATH) // <3>
					.dynamicEnvironment( // <4>
							Map.of(
									"$quoteFieldsToQuery", "LineItemCount, CalculationStatus",
									"$qliFieldsToQuery", "Id, Product2Id",
									"$qlrFieldsToQuery", "Id, QuoteId, MainQuoteLineId, AssociatedQuoteLineId"))
					.customDynamicVariableGenerator( // <5>
							"$unitPrice",
							(ignore1, ignore2, ignore3) -> String.valueOf(Random.Default.nextInt(999) + 1))
					.nodeModulesPath("js") // <6>
					.haltOnFailureOfTypeExcept(
							HTTP_STATUS,
							afterAllStepsContainingHeader("ignoreHTTPStatusUnsuccessful")) // <7>
					.requestConfig( // <8>
							unmarshallRequest(
									beforeStepContainingURIPathOfAny(PQ_URI_PATH),
									PlaceQuoteInputRepresentation.class,
									adapter(PlaceQuoteInputRepresentation.class)))
					.responseConfig( // <9>
							unmarshallResponse(
									afterStepContainingURIPathOfAny(PQ_URI_PATH),
									PlaceQuoteOutputRepresentation.class),
							unmarshallResponse(
									afterStepContainingURIPathOfAny(COMPOSITE_GRAPH_URI_PATH),
									CompositeGraphResponse.class,
									CompositeGraphResponse.ADAPTER))
					.hooks( // <10>
							pre(
									beforeStepContainingURIPathOfAny(PQ_URI_PATH),
									(step, requestInfo, rundown) -> {
										if (requestInfo.containsHeader(IS_SYNC_HEADER)) {
											LOGGER.info("This is a Sync step: {}", step);
										}
									}),
							post(
									afterStepContainingURIPathOfAny(PQ_URI_PATH),
									(stepReport, ignore) -> {
										validatePQResponse(stepReport); // <11>
										final var isSyncStep =
												stepReport.responseInfo.get().containsHeader(IS_SYNC_HEADER);
										if (!isSyncStep) {
											LOGGER.info(
													"Waiting in PostHook of the Async Step: {}, for the Quote's Asynchronous processing to finish",
													stepReport.step);
											// ! CAUTION 10/09/23 gopala.akshintala: This can be flaky until
											// polling is implemented
											Thread.sleep(5000);
										}
									}),
							post(
									afterStepContainingURIPathOfAny(COMPOSITE_GRAPH_URI_PATH),
									(stepReport, ignore) -> validateCompositeGraphResponse(stepReport)),
							post(
									afterStepName("query-quote-and-related-records"),
									(ignore, rundown) -> assertAfterPQCreate(rundown.mutableEnv)))
					.globalCustomTypeAdapter(new IDAdapter()) // <12>
					.insecureHttp(true) // <13>
					.off()); // Kick-off
assertThat(pqRundown.firstUnIgnoredUnsuccessfulStepReport()).isNull(); // <14>
assertThat(pqRundown.mutableEnv)
	.containsAtLeastEntriesIn(
			Map.of(
					"quoteCalculationStatusForSkipPricing", PricingPref.Skip.completeStatus,
					"quoteCalculationStatus", PricingPref.System.completeStatus,
					"quoteCalculationStatusAfterAllUpdates", PricingPref.System.completeStatus));
```

--------------------------------

### Accessing Mutable Environment in Pre/Post-Step Hooks (Java/Kotlin)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

The `rundown.mutableEnv` reference provides access to the mutable environment within ReṼoman's Pre-Step and Post-Step Hooks. This allows for programmatic modification and data passing between steps during test execution, offering a more intuitive debugging experience compared to Postman scripts.

```Java/Kotlin
rundown.mutableEnv
```

--------------------------------

### ReVoman Rundown and StepReport Data Structures (Kotlin)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This Kotlin snippet defines the `Rundown` and `StepReport` data classes, which encapsulate the results of a ReVoman execution. `Rundown` contains a list of `StepReport` objects and the final environment state, while `StepReport` details the outcome of individual steps, including request/response info and any failures.

```Kotlin
Rundown(
	val stepReports: List<StepReport>,
	val mutableEnv: PostmanEnvironment<Any?>)

StepReport(
	step: Step,
	requestInfo: Either<RequestFailure, TxnInfo<Request>>? = null, // <1>
	preStepHookFailure: PreStepHookFailure? = null,
	responseInfo: Either<ResponseFailure, TxnInfo<Response>>? = null,
	postStepHookFailure: PostStepHookFailure? = null,
	envSnapshot: PostmanEnvironment<Any?> // <2>
)
```

--------------------------------

### Accessing Postman Environment Snapshot in StepReport (Java/Kotlin)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

Each `StepReport` object includes a `pmEnvSnapshot` property, which captures the state of the Postman environment at the time of that step's execution. This snapshot is crucial for asserting expected step execution and comparing environment states across different steps to track progress.

```Java/Kotlin
pmEnvSnapshot
```

--------------------------------

### Converting Mutable Environment to Postman JSON Format (Java/Kotlin)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

The `rundown.mutableEnv.postmanEnvJSONFormat()` method converts the current mutable environment state into a Postman-compatible JSON format. This enables easy manual troubleshooting by allowing users to copy and import the generated environment directly into Postman for debugging.

```Java/Kotlin
rundown.mutableEnv.postmanEnvJSONFormat()
```

--------------------------------

### Adding ReṼoman Dependency with Gradle Kts

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This snippet illustrates how to add ReṼoman as an implementation dependency in a Gradle project using the Kotlin DSL (.kts). It uses the groupId:artifactId:version format, with {revoman-version} as a placeholder for the library's specific version.

```Kotlin
implementation("com.salesforce.revoman:revoman:{revoman-version}")
```

--------------------------------

### Defining a Post-Transaction Step Pick Hook in Java

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This Java lambda expression defines a `postTxnStepPick` hook, which is executed after a step completes. It logs the display name of the executed step, demonstrating a simple post-execution action within the ReṼoman framework.

```java
final var postTxnStepPick = (stepReport, rundown) -> LOGGER.info("Picked `postLogHook` after stepName: {}", stepReport.step.displayName)
```

--------------------------------

### Adding ReṼoman Dependency with Bazel

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This snippet shows the Bazel syntax for declaring a dependency on the ReṼoman library. It uses the standard Maven-like coordinate format groupId:artifactId to reference the library, with the version being managed externally by Bazel's dependency resolution.

```Bazel
"com.salesforce.revoman:revoman"
```

--------------------------------

### Adding ReṼoman Dependency with Maven

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This snippet demonstrates how to include the ReṼoman library as a dependency in a Maven project's pom.xml file. It specifies the groupId as com.salesforce.revoman, artifactId as revoman, and uses a placeholder {revoman-version} for the version, which will be substituted by Maven.

```XML
<dependency>
	<groupId>com.salesforce.revoman</groupId>
	<artifactId>revoman</artifactId>
	<version>{revoman-version}</version>
</dependency>
```

--------------------------------

### Force Adding node_modules to Git Repository (Shell)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This shell command is used to force-add the `node_modules` directory to a Git repository, even if it is listed in the `.gitignore` file. This is useful when `node_modules` is typically ignored but needs to be checked into version control for specific reasons.

```Shell
git add --all -f <path>/node_modules
```

--------------------------------

### Overriding Hooks in Revoman Configuration (Java)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This snippet demonstrates how to override existing hooks in a `Revoman` configuration. It shows how to create a new immutable configuration instance by combining existing hooks with new ones using `kotlin.collections.CollectionsKt.plus`, as direct `add` or `append` methods are not available for iterable attributes. This ensures controlled modification of configuration attributes.

```Java
COMMON_CONFIG.overrideHooks(kotlin.collections.CollectionsKt.plus(COMMON_CONFIG.hooks(), post(.../*My Hooks*/))
```

--------------------------------

### Reading Mutable Environment Value as Strong Type (Java/Kotlin)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

The `rundown.mutableEnv.<TypeT>getTypedObj()` method allows reading values from the mutable environment and casting them to a specified strong type (`TypeT`). This provides type safety and simplifies data retrieval from the environment within ReṼoman's test logic.

```Java/Kotlin
rundown.mutableEnv.<TypeT>getTypedObj()
```

--------------------------------

### Setting Postman Environment Variables (JavaScript)

Source: https://github.com/salesforce-misc/revoman/blob/master/README.adoc

This JavaScript function, `pm.environment.set()`, is used within Postman's pre-request or post-response scripts to set or update environment variables. It allows for dynamic modification of the shared mutable environment during API test execution.

```JavaScript
pm.environment.set()
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.