nushell/crates/nu-plugin-test-support/Cargo.toml

[package]
name = "nu-plugin-test-support"
version = "0.92.3"
edition = "2021"
license = "MIT"
description = "Testing support for Nushell plugins"
repository = "https://github.com/nushell/nushell/tree/main/crates/nu-plugin-test-support"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
nu-engine = { path = "../nu-engine", version = "0.92.3", features = ["plugin"] }
nu-protocol = { path = "../nu-protocol", version = "0.92.3", features = ["plugin"] }
nu-parser = { path = "../nu-parser", version = "0.92.3", features = ["plugin"] }
nu-plugin = { path = "../nu-plugin", version = "0.92.3" }
nu-cmd-lang = { path = "../nu-cmd-lang", version = "0.92.3" }
nu-ansi-term = { workspace = true }
similar = "2.5"

[dev-dependencies]
typetag = "0.2"
serde = "1.0"
Add test support crate for plugin developers (#12259) # Description Adds a `nu-plugin-test-support` crate with an interface that supports testing plugins. Unlike in reality, these plugins run in the same process on separate threads. This will allow testing aspects of the plugin internal state and handling serialized plugin custom values easily. We still serialize their custom values and all of the engine to plugin logic is still in play, so from a logical perspective this should still expose any bugs that would have been caused by that. The only difference is that it doesn't run in a different process, and doesn't try to serialize everything to the final wire format for stdin/stdout. TODO still: - [x] Clean up warnings about private types exposed in trait definition - [x] Automatically deserialize plugin custom values in the result so they can be inspected - [x] Automatic plugin examples test function - [x] Write a bit more documentation - [x] More tests - [x] Add MIT License file to new crate # User-Facing Changes Plugin developers get a nice way to test their plugins. # Tests + Formatting Run the tests with `cargo test -p nu-plugin-test-support -- --show-output` to see some examples of what the failing test output for examples can look like. I used the `difference` crate (MIT licensed) to make it look nice. - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting - [ ] Add a section to the book about testing - [ ] Test some of the example plugins this way - [ ] Add example tests to nu_plugin_template so plugin developers have something to start with 2024-03-23 19:29:54 +01:00			`[package]`
			`name = "nu-plugin-test-support"`
Bump version to `0.92.3` (#12476) 2024-04-12 15:00:43 +02:00			`version = "0.92.3"`
Add test support crate for plugin developers (#12259) # Description Adds a `nu-plugin-test-support` crate with an interface that supports testing plugins. Unlike in reality, these plugins run in the same process on separate threads. This will allow testing aspects of the plugin internal state and handling serialized plugin custom values easily. We still serialize their custom values and all of the engine to plugin logic is still in play, so from a logical perspective this should still expose any bugs that would have been caused by that. The only difference is that it doesn't run in a different process, and doesn't try to serialize everything to the final wire format for stdin/stdout. TODO still: - [x] Clean up warnings about private types exposed in trait definition - [x] Automatically deserialize plugin custom values in the result so they can be inspected - [x] Automatic plugin examples test function - [x] Write a bit more documentation - [x] More tests - [x] Add MIT License file to new crate # User-Facing Changes Plugin developers get a nice way to test their plugins. # Tests + Formatting Run the tests with `cargo test -p nu-plugin-test-support -- --show-output` to see some examples of what the failing test output for examples can look like. I used the `difference` crate (MIT licensed) to make it look nice. - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting - [ ] Add a section to the book about testing - [ ] Test some of the example plugins this way - [ ] Add example tests to nu_plugin_template so plugin developers have something to start with 2024-03-23 19:29:54 +01:00			`edition = "2021"`
			`license = "MIT"`
Add missing crate description to nu-plugin-test-support (#12368) 2024-04-03 15:33:18 +02:00			`description = "Testing support for Nushell plugins"`
Add test support crate for plugin developers (#12259) # Description Adds a `nu-plugin-test-support` crate with an interface that supports testing plugins. Unlike in reality, these plugins run in the same process on separate threads. This will allow testing aspects of the plugin internal state and handling serialized plugin custom values easily. We still serialize their custom values and all of the engine to plugin logic is still in play, so from a logical perspective this should still expose any bugs that would have been caused by that. The only difference is that it doesn't run in a different process, and doesn't try to serialize everything to the final wire format for stdin/stdout. TODO still: - [x] Clean up warnings about private types exposed in trait definition - [x] Automatically deserialize plugin custom values in the result so they can be inspected - [x] Automatic plugin examples test function - [x] Write a bit more documentation - [x] More tests - [x] Add MIT License file to new crate # User-Facing Changes Plugin developers get a nice way to test their plugins. # Tests + Formatting Run the tests with `cargo test -p nu-plugin-test-support -- --show-output` to see some examples of what the failing test output for examples can look like. I used the `difference` crate (MIT licensed) to make it look nice. - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting - [ ] Add a section to the book about testing - [ ] Test some of the example plugins this way - [ ] Add example tests to nu_plugin_template so plugin developers have something to start with 2024-03-23 19:29:54 +01:00			`repository = "https://github.com/nushell/nushell/tree/main/crates/nu-plugin-test-support"`

			`# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html`

			`[dependencies]`
Bump version to `0.92.3` (#12476) 2024-04-12 15:00:43 +02:00			`nu-engine = { path = "../nu-engine", version = "0.92.3", features = ["plugin"] }`
			`nu-protocol = { path = "../nu-protocol", version = "0.92.3", features = ["plugin"] }`
			`nu-parser = { path = "../nu-parser", version = "0.92.3", features = ["plugin"] }`
			`nu-plugin = { path = "../nu-plugin", version = "0.92.3" }`
			`nu-cmd-lang = { path = "../nu-cmd-lang", version = "0.92.3" }`
Fix #12280: replace `difference` crate with `similar` (#12282) Fixes #12280. # Description This removes the dependency on the `difference` crate, which is unmaintained, for `nu-plugin-test-support`. The `similar` crate (Apache-2.0) is used instead, which is a bit larger and more complex, but still suitable for a dev dep for tests. Also switched to use `crossterm` for colors, since `similar` doesn't come with any terminal pretty printing functionality. # User-Facing Changes None - output should be identical. # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` 2024-03-26 03:13:12 +01:00			`nu-ansi-term = { workspace = true }`
Bump similar from 2.4.0 to 2.5.0 (#12375) 2024-04-07 23:50:11 +02:00			`similar = "2.5"`
Add test support crate for plugin developers (#12259) # Description Adds a `nu-plugin-test-support` crate with an interface that supports testing plugins. Unlike in reality, these plugins run in the same process on separate threads. This will allow testing aspects of the plugin internal state and handling serialized plugin custom values easily. We still serialize their custom values and all of the engine to plugin logic is still in play, so from a logical perspective this should still expose any bugs that would have been caused by that. The only difference is that it doesn't run in a different process, and doesn't try to serialize everything to the final wire format for stdin/stdout. TODO still: - [x] Clean up warnings about private types exposed in trait definition - [x] Automatically deserialize plugin custom values in the result so they can be inspected - [x] Automatic plugin examples test function - [x] Write a bit more documentation - [x] More tests - [x] Add MIT License file to new crate # User-Facing Changes Plugin developers get a nice way to test their plugins. # Tests + Formatting Run the tests with `cargo test -p nu-plugin-test-support -- --show-output` to see some examples of what the failing test output for examples can look like. I used the `difference` crate (MIT licensed) to make it look nice. - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting - [ ] Add a section to the book about testing - [ ] Test some of the example plugins this way - [ ] Add example tests to nu_plugin_template so plugin developers have something to start with 2024-03-23 19:29:54 +01:00
			`[dev-dependencies]`
			`typetag = "0.2"`
			`serde = "1.0"`