-
-
Notifications
You must be signed in to change notification settings - Fork 160
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
Add mocks for some builtin types for use when Godot isn't running #701
Comments
I tried something like this in the early days, until I discovered how broken This is a particularly funny commit: 698e21b I tried a lot of things, but it's very hard to satisfy So, we can gladly try another angle, but:
So maybe there's a very lightweight way to do this, but imo it's not worth the cost of massive reconfiguration across crates. We need to ask ourselves what the goal would be -- if we want to test the integration, then stubs/mocks don't provide that, and we already have itests for this purpose. If we want to demonstrate features, we can currently do that with |
well for instance if i want to test some helper functions implemented on im not suggesting we're going to be testing |
Here is a concrete example from me working on /// Change the `hint` and `hint_string` to be the given `hint_info`.
///
/// See [`export_info_functions`](crate::property::export_info_function) for functions that return appropriate `PropertyHintInfo`s for
/// various Godot annotations.
///
/// # Examples
///
/// Creating an `@export_range` property.
///
// TODO: Make this nicer to use.
/// ```no_run
/// # use crate::property::export_info_function;
/// # use crate::builtin::meta::PropertyInfo;
///
/// let property = PropertyInfo::new_export::<f64>("my_range_property")
/// .with_hint_info(export_info_function::export_range(
/// 0.0,
/// 10.0,
/// Some(0.1),
/// false,
/// false,
/// false,
/// false,
/// false,
/// false,
/// ))
/// ```
pub fn with_hint_info(self, hint_info: PropertyHintInfo) -> Self {
let PropertyHintInfo { hint, hint_string } = hint_info;
Self {
hint,
hint_string,
..self
}
} This doctest does not actually care about any godot-specific details of |
I see, thanks for the example! In this case, a mock could probably live in a dedicated module, whose import is hidden with But how can we easily keep the mock and the real API in sync? Because if we need to duplicate code, we may as well just duplicate the doctest into an integration test... |
IMO the Less type-changes: the better. Doctest could check only for compile errors with |
In some cases it would be nice to be able to use at least some basic features of some builtin types even when Godot isn't running.
For instance, in doctests we cannot use
GString
orStringName
because they only work when Godot is running. However these are "just" strings. It would be nice if we could make doctests and unit tests for types and functions that use these types anyway.This should only be used in cases where the exact values and behavior of these types is not what's being tested beyond some basic features, such as equality.
We could override some of the ffi-functions with stubs/mocks when Godot isn't running. And maybe we should make it an explicit opt-in, like for instance we could have a global function
pub unsafe fn enable_builtin_mocks()
function to enable this. This should be unsafe imo because otherwise we may need to reimplement a lot of functionality for relevant types as we may rely on some behavior for safety.The text was updated successfully, but these errors were encountered: