Document expect_length() and expect_shape() together

[hadley]

@MichaelChirico thinking about it more, I think it makes sense to not introduce a duplicated way to test for length, but we should keep expect_length() and expect_shape() close together.

[MichaelChirico]

I'm fine with that; WDYT about dropping the "shape" concept and just using expect_nrow(), expect_ncol(), and expect_dim()?

[hadley]

Hmmm, that's a good question. My gut feeling is that I don't like it because it increases the number of functions by quite a bit, mostly for concepts that are tightly related. It also feels out of keeping with functions like expect_error() that can do a lot, and while I think somewhat regret the fact that testthat provides a small number of complex expectations instead of a larger number of simpler expectations, I don't want to walk back that decision now.

[MichaelChirico]

Somewhat rambling, but some thoughts:

The expect_error() example is interesting, we have that but also expect_condition(class="error"), that suggests to me expect_shape(length=) as a good analogue.

OTOH, splitting out expect_shape() would increase the number of testthat::expect_ exports from ~58 to 60.

I guess a useful exercse is to imagine in 5 years sitting down to write a fresh suite of tests, will it be easier to reach for expect_shape(nrow=) or expect_nrow(? And for the next test, will it be easier to then reach for expect_shape(dim= or expect_dim(? I don't have a strong prior, I guess it's roughly a wash. With the former we anchor on expect_shape and then can get auto-complete for the argument name, with the latter expect_<tab-tab> will show a flood of names. In both cases they'll share an Rd file.

(I also wonder whether it matters for which is easier for LLMs to pick up on)

[hadley]

Hmmm, I think I'd find expect_shape_nrow() etc more compelling since it does help more with autocomplete. But there's something I like about expect_shape() as it is.

[hadley]

I've merged since I think it's an improvement over the current state, and there's something about the individual functions that feels out of keeping with testthat to me.