-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Add a few basic tests for asset processing. #21409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
fb9e912
to
fe96cb6
Compare
#[expect(clippy::allow_attributes, reason = "this is only sometimes unused")] | ||
#[allow( | ||
unused, | ||
reason = "We only use this for asset processor tests, which are only compiled with the `multi_threaded` feature." | ||
)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of doing all these expect/allow, why not make a submodule for the asset processor tests and mark the entire thing as #[cfg(feature = "multi_threaded")]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I'm not a fan of how indented additional test modules are. We could also split this into its own file, but I don't know if that's a pattern in bevy yet.
I also think we should try to make asset processing work single threaded at least for testing. I think the main reason we don't support single-threaded right now is because listening for changes right now effectively uses a spin loop.
@alice-i-cecile WDYT? We may want these tests in a separate module anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A separate file would also make sense since were at 2k+ lines. In general I feel like a lot of the files in bevy_asset could use being split up, I always have a hard time remembering where stuff is in these big files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong feelings here TBH 😅
self: Pin<&mut Self>, | ||
_: &mut core::task::Context<'_>, | ||
) -> Poll<std::io::Result<()>> { | ||
// Write the data to our fake disk. This means we will repeatedly reinsert the asset. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im not sure I understand why there's both a DataWriter and MemoryAssetWriter. Is DataWriter also a memory writer? If not, why is this a fake disk?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MemoryAssetWriter implements the AssetWriter trait - which is really an interface over the file system to start writes, move directories, etc.
DataWriter implements the AsyncWrite trait that actually writes data.
This just mirrors the existing MemoryAssetReader and DataReader types. I'd like to keep that consistent.
@andriyDev @mockersf it looks like the example patch is failing now? |
Oh hey this is very cool, I have a branch that I haven't even pushed to github because my test requires writing files and I wasn't sure how to do that safely in a test! |
fe96cb6
to
694b9a3
Compare
@alice-i-cecile I just recreated the I also realized I was missing a migration guide for the new |
694b9a3
to
0bf082a
Compare
Objective
bevy_asset
needs more tests! This adds three related to asset processing.Solution
MemoryAssetWriter
to pair withMemoryAssetReader
.Data::value
andData::path
pub
so that we can actually see what is written to the processed dir. Note:Dir::get_asset
returnsData
already, but it isn't usable.Testing