Closed chitoyuu closed 1 year ago
bors try
What's the reason for moving the tests? Or when should integration tests be part of the implementation file, vs. inside
/test
?
The immediate reason is that the test crate is no longer able to access some of the test functions, that were glob re-exported before the changes, and I feel like this is the most natural way to deal with that, moving the list closer to the definition site of the tests themselves.
The general problem imo depends on the scope of the tests. Things that depend on the proc-macros or the generated API by necessity have to live inside /test
. For things that test specific core_types
I think it's fine for them to be placed closer to the implementations they test. You can call the former "integration" integration tests and the latter "unit" integration tests, I suppose. I don't find the current organization to be particularly problematic.
bors r+
This is a breaking change because avoiding ambiguous globs means that the ambiguous types must be removed from the public interface. I have taken the chance to remove some other dubiously useful type from the top
core_types
module as well. The submodules that contained those types are made public.The
variant_array
module has been renamed toarray
for simplicity.