# testing nu-cmd-lang

Integration testing inside the nu-cmd-lang crate is the ability to run the integration tests as if the only command crate in your system is the base crate called nu-cmd-lang. The motivation for this crate is so that folks can come along and develop software architectures that sit on top of this crate without having all of the baggage / dependencies of everything that lives in nu-command.

## Background on the crate = nu-cmd-lang

Some background on why this crate was created... This crate is here as the base language / command crate of nu. These are the core commands needed to have a nice working version of the *nu language* without all of the support that the other commands provide inside nushell. Prior to this crate landing in nushell all of our commands were housed in the crate *nu-command* Moving forward we would like to bust out the commands "slowly" into different crates, the naming and how this will work and where all the commands will be located is a "work in progress". Especially now that the *standard library* is starting to gain lots of positive traction. As time goes on more commands written in rust currently will move to the standard library.

## First thoughts on how the testing infrastructure will work

When the tests run their only dependency will be the *nu-cmd-lang* [default_context.rs](https://github.com/nushell/nushell/blob/main/crates/nu-cmd-lang/src/default_context.rs)

By sandboxing the integration tests that live inside this crate we are guaranteeing that if a developer came along and grabbed this crate and put it into another software system the integration tests (along with all of the examples) would pass providing the other nushell plumbing crates were there.

But the key point is the nu-command crate is not part of the picture :smiley:

## Initial possible solutions

Currently the nu! macro is one of our main drivers for integration testing. It works great but is not appropriate for this particular crate because of the sandboxing requirement. Therefore we need another way to test.

It has been proposed that we could possibly do our integration testing similar to the way we do [example testing](https://github.com/nushell/nushell/blob/main/crates/nu-cmd-lang/src/example_support.rs#L214) which is to eval the code

fn eval(
    contents: &str,
    input: PipelineData,
    cwd: &std::path::Path,
    engine_state: &mut Box<EngineState>,
) -> Value {
    let (block, delta) = parse(contents, engine_state);
    eval_block(block, input, cwd, engine_state, delta)
}

and then compare it to what you expect to come back. This would avoid the "heavy weight" process of firing up a nushell process for each test which is currently the way the nu! macro works.

## [References](https://hackmd.io/c8OYzLXNRO-5PO0BNQYRgw)