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 摘要。