Seems like this should have a result other than None, right?

Would be nice. I did try to provide an example result, but had to remove it. There are two reasons it will currently fail. First, since the return type doesn't match the function signature, I'm assuming it will fail because of this. This is the same reason we don't have an example here, so it looks like this problem has been around for at least 2 years.

But even if that were in place, it also fails because transpose doesn't seem to be currently allowed in tests, at least not outside it's own function, I assume. It looks like only "core commands" are allowed. Any other command results in RunExternalNotFound error.

For the first problem, I'm wondering if that is a useful test in the first place? If (in general for all Nushell) most of the examples are demonstrating the output of the command, doesn't that also test the return type? In other words, the result is of a particular return type -- Usually that of the command itself. So testing the example matches the signature seems redundant.

For the second problem:

1. I'm wondering how worthwhile this "optimization" of only loading a bare-minimum of commands is at this point. I definitely want to get through all tests as quickly as possible ;-), but we're down to single-digit milliseconds of startup time even when parsing std/core using the "full" command set.

   Of course, reworking this would be a significant undertaking, so I'd like to avoid it ... for now.

2. I'm not sure if there's a way to easily add a "non-core" command like transpose to the "allowed" list, but I'm not sure even that's worthwhile here.

So ... I left it with no sample-result.

I do have a plan that I'd like to implement in the near-term for this that would allow us to provide more complete examples for all commands. More details to come on that later.

For now, is it okay if we just skip the result on this one?

Thanks for spelling it out for me. Appreciate it.

Problem 1a: At a minimum, having comments of why it's not being tested would've prevented me or others from asking the question.

Problem 1b: check_example_input_and_output_types_match_command_signature() is valid because it tries to force us to have examples for each input and output type. I think it's good practice even though we override it in way too many places. In a perfect world, it would be overridable, and we'd have examples for every i/o type.

Problem 1c: If a table isn't a valid output of into record then it probably shouldn't be in an example, rather it should be in a unit/integration test. That's taking the hard line and I'm sure there are exceptions to that rule.
 
Problem 2: I'd rather have everything testable but have the minimum commands because the real issue is about compile time. I think that's why only a few are added. I think if we have a valid test and the command isn't available, we should add the commands that test the command in the example.

1a. Absolutely, and apologies. It definitely should have been in the PR comments.

1b. I think you are referring to a different test -- check_all_signature_input_output_types_entries_have_examples(), right? I agree that's good practice even though too commonly overridden.

...have_examples() can be overridden, as you mention. This is the "positive" test for type-signatures. Each signature should have an example/test.

...match_command_signatures() can't be bypassed. But this is the one where I was questioning its usefulness. That said, I kind of see the purpose now -- It's the "negative" version, saying "if a command is returning a type that isn't in its signature, something is very, very wrong". We just need a way to suppress this test, preferably on individual examples rather than the command itself.

1c. If it were primarily a test, I'd agree. But this is an example for user-documentation first-and-foremost, and the fact that it is also used for a test is limiting its usefulness as documentation. Don't get me wrong - I think it's great that we get some extra test coverage by testing examples, but that shouldn't get in the way of providing good documentation, IMHO.

2. Re:"if we have a valid test" - But do we really care if this example (which is purely to demonstrate how to replace date to-table) is tested? We just want to provide the sample result to the user. If we wanted a test around it, that could be easily added to the tests themselves, I believe. We just don't have a way to suppress test on an individual example today. That's really (to me) the core issue. We could provide so many more "example results" to things like ls (or seq char) if we could suppress the tests on them.

   Re:"I think if we have a valid test and the command isn't available, we should add the commands that test the command in the example."

   Are you saying that we should add transpose to the allowed commands? I'm not sure how easy that is, as currently the only commands that are allowed are in nu-cmd-lang already, I believe?

Are you saying that we should add transpose to the allowed commands? I'm not sure how easy that is, as currently the only commands that are allowed are in nu-cmd-lang already, I believe?

I believe you should be able to use test_examples_with_commands, this is how I used last in help sort-by.