0xMiden / 0xMiden/node

Consistency tests, test utils and expose test helpers

未关闭
#1,233 1 条评论 2 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Rust
星标
104
派生
138
平均合并
1 天 13 小时
30 天内合并 PR
56

描述

Currently we still have a few `testing` flags that expose additional public API. Oftentimes we do this to provide API we do not want to become public API, deliberately.

Proposal on directory structuring:

* always make `mod tests;` a separate file, but keep them in the same directory and crate
* move any mocking or dummy generation utilities for tests specifically into a `${cratename}-test-helpers` crate living in the same directory, this one can and _should_ depend on the `${cratename}`, it's for use by other crates - particularly useful for projects with more and smaller crates - we should strive in that direction

with these two small changes, test utilities are moved always where they should be, outside the actual crate and hence not public API, yet it's a unified place and naming scheme how to depend on them / find them

# Proposal on feature `"testing"` removal

The intent is to expose an API that is commonly not meant to be used by users.

While I do see the value in an established set of libraries, I recommend to expose more of `X::dangerous_construct` or `X::new_unchecked` (the latter is also present in the rust std library, commonly used with unsafe, where the former is used in codebases that want delineate logic assumptions vs memory safety, I would recommend to use the former unless it's a mem saftey issue specifically since the code doesn't become any cleaner sprinkling `unsafe {}` into it).

The risk of additive features is a single slip-up, taking a shortcut for a needed API gated behind `testing`, effectively makes all of that crates API public API through the feature unification path of `cargo`.

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。