Testing and mocking based on name conversion

compiler
23

It fits better in languages like Python, or like I said in DSLs.

If you think name conversion is only applicable to non-system languages, can you give some ideas on what system languages ​​and non-system languages ​​can do?

I have also used functions and macros in unusual-but-perfectly-valid ways

If a function or macro is counterintuitive (I mean its behavior is inconsistent with its name), then I consider the function itself to be bad code(and magic). For example c++'s string::find_first_of

24

When we are arguing about a certain point, I think it may be more convincing if we list some evidence. For example, list some evidence in white papers, official documents, and papers. Or just list some statistics.

This is much better than "it can be inferred from xxx", "we have been doing this for ten years", "xxx is not suitable for..."

If we propose a new concept, we need to define it and explain it. After all, computer science is a science, and science is always precise.

25

I do actually :sweat_smile:

26

Well, I think you are not in a position to ask that. @jjpe is just helping you by giving information/data points about the language and probably saving precious time so you won't write an RFC that will not get approved anyways. Evidence like "white papers, official documents, and papers" is usually expected from the side changing the status quo first, you in that particular case.

3 Likes
27

Please use evidence to refute my point of view. Instead of authority and "help"

28

Some corner cases that come to mind:

For testing, what is the file's position in the module hierarchy? Can xxx_test.rs access non-pub members of xxx.rs? What is its module path to support exposing specific APIs via pub(in …)? What file is considered to have its mod statement (e.g., if I have #[cfg(cond)] mod xxx;, does this also mask xxx_test automatically or do I need another #[cfg] to handle it)?

For mocks, what makes the mock "active"? If I have xxx_mock.rs and xxx_test.rs, does xxx_test get access to xxx or xxx_mock APIs? If the latter, how do I actually test xxx APIs? Personally, I'm not a fan of mock APIs and would much rather use traits as the boundary that testing can shim into (e.g., I have crates that, in production, talk to GitLab and Github while testing basically does the minimum behavior expected of a forge such as webhooks and "API" requests; there is still an end-to-end integration test for GitLab at least). I'd be rather disappointed to see anything like mocking support baked into the language at the module level without a comprehensive way to mock out APIs as well. Also some way to "compare" APIs in the "real" and "mock" modules and diagnose differences.

In any case, the status quo is set and it is incumbent upon those that want to change it to make their argument to move away from it. How Rust got to its current state isn't really all that relevant to arguments to change it IMO. I, personally, also really don't find "but lang X does it" (in this case…Ruby and Golang seem to have similar behaviors at least as far as tests are concerned?) all that convincing either for that matter.

3 Likes
29

Your questiones are very good. I will try to answer your question here.

For testing, what is the file's position in the module hierarchy?

I think xxx_test.rs has the same hierarchy with xxx.rs.

Can xxx_test.rs access non-pub members of xxx.rs ?

No, it cannot, xxx_test.rs can only test pub members of xxx.rs.1

What file is considered to have its mod statement.

The file contains xxx.rs will contain xxx_test.rs(compiler will insert mod xxx_test implicit. Yes, this is actually a sugar). And if xxx.rs be masked by cfg, then xxx_test.rs will be masked also.

For mocks, what makes the mock "active"?

Here, mock is considered as a tool to assist unit testing. So cfg(test) will active xxx_mock.rs

If I have xxx_mock.rs and xxx_test.rs , does xxx_test get access to xxx or xxx_mock APIs?

If you have both xxx_test.rs and xxx_mock.rs, then you cannot access xxx.rs's methods. As mentioned above, mock is considered as a tool to assist unit testing. If you only need mock a subset of functions of a module, a better approach is to extract it into a submodule. Then create submodule_mock.rs.

Also some way to "compare" APIs in the "real" and "mock" modules and diagnose differences.

I think the purpose of mock is to build a simulated environment for unit testing, such as returning some pre-prepared data when calling IO interface. More complex situations should be handled by integration testing. After all, unit testing only tests units. We should carefully handle the boundary between unit testing and integration testing.

I, personally, also really don't find "but lang X does it" all that convincing either for that matter.

Yes. I mention these points solely to provide empirical evidence that grounds my argument, ensuring it is not mere speculation.

When you look at my answers, you'll see that I add some references. Which are to provide some factual basis. They are not means "XXX did this, so we should do this too"

30

Hi, sorry. I re-read the post again. I understand what you mean.

Is it possible to implement a syntax like you propose with a procedural macro library (instead of adding it to the standard library)?

And. If we switch to talk a new syntax, is that off this post's topic?