You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Find a way to make perfect, deep copies of modules that allow for their state to be modified
Write modules so that they don't need to modify the state of other modules
The first one is a pipe dream, since making deep copies of tables is a known serialization challenge in Lua, and would be difficult to do in pure Lua.
The second sounds more achievable, but currently the emit module allows recording the output, so modules like that wouldn't be able to be easily tested.
I think I'll have to settle for less than 100% test coverage, having to write modules to make them easier to test, and relying less on module state and more on function closures.
Also, currently, if amalg wraps modules up in the same way they currently are (i.e. with a function in the package.preload table), then the module can be cleared from package.loaded and re-required to "reset" it.
I don't think it would be a good idea to implement this, though, as it wouldn't really give any guarantees about preventing state manipulation.
Currently, functions under test can affect state outside of their sandbox by requiring a module or package be accessible, and modifying that module.
For example:
This could be solved a variety of ways:
The first one is a pipe dream, since making deep copies of tables is a known serialization challenge in Lua, and would be difficult to do in pure Lua.
The second sounds more achievable, but currently the
emit
module allows recording the output, so modules like that wouldn't be able to be easily tested.I think I'll have to settle for less than 100% test coverage, having to write modules to make them easier to test, and relying less on module state and more on function closures.
Also, currently, if
amalg
wraps modules up in the same way they currently are (i.e. with a function in thepackage.preload
table), then the module can be cleared frompackage.loaded
and re-require
d to "reset" it.I don't think it would be a good idea to implement this, though, as it wouldn't really give any guarantees about preventing state manipulation.
I think when it's necessary,
luassert
's built in table copying should be where I look.The text was updated successfully, but these errors were encountered: