Function interfaces for tests about rust HOT 8 CLOSED

@stevejb71 @petertseng @NobbZ -- do you have any ideas about how we could solve this?

from rust.

To be honest, this is the exercise I'm stuck with too, I don't even know
why I'm called in here 😁

But yes, here the tests do a very strongly depend on the data structure
where possibly is no need for.

Also for the sake of the exercise it should not matter if you use the named
fields or tuple syntax.

Anyway, I will take a closer look tomorrow when I'm back at my laptop and
no one else chimed in.

Katrina Owen [email protected] schrieb am Mo., 11. Jan. 2016 20:26:

@stevejb71 https://github.com/stevejb71 @petertseng
https://github.com/petertseng @NobbZ https://github.com/NobbZ -- do
you have any ideas about how we could solve this?

—
Reply to this email directly or view it on GitHub
#64 (comment).

from rust.

@NobbZ I called you because you've commented a lot in the rust track :)

from rust.

@kytrinyx A reasonable approach is taken here.

from rust.

Yeah, that looks good.

from rust.

Yeah, the expected interface being thrown in a comment somewhere seems good. Probably in the stub file would be in a more visible location than the test file, even?

On a related note, I've been trying to think about getting tests to be less constraining of implementation details these days. Do you think doing Allergies(0) is too constraining and it should be Allergies::new(0) instead?

(and the example impl can just have fn new(n: uint) -> Allergies { Allergies(n) } or similar, and anyone else can do whatever they want)

from rust.

Yeah, one could give a list of functions and signatures in the impl, thats one good thing, but not the solution to the OPs problem.

The OP assumed the design of the type would be as usual. So he designed a struct using record-syntax and used a static function new in the impl to create new values of the type. This is quite a common pattern in rust.

There is another kind of structs, using tuplesyntax. There fields don't have a name, and the structs name is used as if it were the new function.

Both have some pros and cons, eg tuplesyntax is much nicer to pattern match on, while recordsyntax is much more self documenting due to the named fields.

I have seen both in the wild, but the section about tuple syntax in the official rust manual is very short, while record syntax is explained exhaustively.

So I'd prefer to not make any assumption in any future tests that make assumptions about the used syntax, but always use a static constructor in the impl and document signature as shown above.

from rust.

So I'd prefer to not make any assumption in any future tests that make assumptions about the used syntax, but always use a static constructor in the impl and document signature as shown above.

Agree.

from rust.