Are you talking about the use of self in the properties/getters/fields section of the spec? I was using self for consistency with the spec in all the other languages which use self/this.

As far as seeing self in other languages that don't have it, the self.___ listings are all in language-conditional blocks, so they will only show in rust. (In fact, each of those listings has a conditional block for each language the kata supports, with each listing using self/this.)

1.Unfortunately not, there's some magic that assert_eq! does that is difficult to replicate. assert_eq! is also the standard for writing tests anyway, so adding an error message should be enough for your average rust programmer.

4.I guess it would be possible, but very ugly and not at all idiomatic. It is not uncommon for tests in the wild to always output a stdout trace, because the compiler and package manager is configured to conditionally block stdout depending on the results of tests and how many are being run. (I think the rust way to solve this problem is set TRACE to true, and let the compiler do the rest.)

Note: I renamed nice_assert_eq to be chem_assert because I keep overloading it with common functionality (checking lists of test strs, checking for errs, etc.)

I took a (minimally-invasive) swing at it. Let me know if there's anything else to be done.

That worked - thanks!

Thanks, it was a good challenge! I use your translations all the time, so the shout out means a lot.

That's a good tip about shifting the mod preloaded into the test suite - change published!

Sure! How do I get on to the discord? The links don't appear to work... :(

1. I have made the macro nice_assert_eq! that aims to make the debug output and the test cases more legible. Let me know what you think.

   As far as missing messages for (what used to be called) property_method_and_locking, could you be more specific? I'm not seeing what's missing, sorry.

2. Index out of bounds errors should no longer occur in the test suite regardless of the length of m.atoms(). In places where non-zero length is expected, there are custom assert statements inserted.

3. I took all your bullet-point suggestions, except for two:

• EmptyMolecule_Err_if_no_branches_after_unlock raises a warning in the compiler. I rephrased it to empty_molecule_err_if_no_branches_after_unlock to avoid that issue.

• You will see many comments inside remove_empty_branches_after_unlocking. The python test implementation actually violates the spec inside the commented-out code. The Final Notes section in the description say that "Methods will always receive valid arguments, e.g. carbon or branch numbers..." Because that line provides an invalid (nc, nb), it triggers undefined behavior. I had removed the test because of this, but I put back everything (but the bad line) so you can take a look.

  A suggestion about how to fix this: we could design it so that mutating (2, 2) would cause an InvalidBond exception/err instead of going out of bounds only if the branches were not updated properly. For example:

  # start same as before
  m = Molecule().brancher(1, 5).bounder((2,2,5,2), (4,2,1,1)).mutate((1,1, "H"))
  # add a new branch C=C=C, maxxing out the 2nd mol on 3rd branch
  m.branch(3).bounder((2,3, 1,3), (2,3, 3,3)) # <<< only new line
  # get rid of branch as before
  m.closer().unlock() 
  # a valid index, but targets a fully bonded carbon now, only errs if done properly!
  test.expect_error( "Should remove any empty branch: 'm.add([2,2,'P'])' shouldn't work, ....",
                     lambda: m.add((2,2,"P")) )
  # if it was done incorrectly, mutating (2,2) to a P would still be ok
  

4. There is a TRACE constant now, set to false.
5. Done!
6. The snippets you wrote are not equivalent. In m.bond(..).expect("something bad happened"), only if bond returns and Err("error data"), then the program will crash (or the test will fail) with stderr:

thread 'tests::example::test' panicked at 'something bad happened: "error data"', src/tests.rs:1234:5
stack backtrace:
    ...

In other words, the calls m.bond(&[(5,1,3,2)]).expect("[...]") works just like the python below from your tests, printing any error that occurred and the message with it:

```python
try:
    m.bounder((5, 1, 3, 2))
except Exception as e:
    print("{}: {}".format(e.__class__.__name__, e))
    test.expect(False, "[...]")
```

Sorry, I'm new to the discourse interface - I replied in a comment above!

1. No problem, I'll do my best to explain and you can ask questions as you like.
2. I did not forget to add the hash impl, I chose not too. The hash function in Rust is almost always written by using a macro (specifically #[derive(Hash)]). Because it was not necessary for the rust implementation of the tests (I never used a map of any kind) and it is very unusual to implement by hand (like JS which does not have a hash requirement, but unlike Python/Java which do), I decided to drop the requirement. I just forgot to remove the comment - sorry!
3. The short answer is yes, it expands to exactly what's written in the spec. mol! is a fairly complex macro, but something like
   mol!("name", fn1(arg1), fn2(arg2, arg3), fn3()) will eventually expand to

let mut m = Molecule::from("name");
(&mut m)
    .fn1(arg1)
    .expect("fn1 failed")
    .fn2(arg2, arg3)
    .expect("fn2 failed")
    .fn3()
    .expect("fn3 failed");
return m;

The expect statements are required for rust error handling, and they do the same thing as ? except that they give the provided error message as well as the default one.
As you can see, most of mol!'s job is to inform the user which function call failed, if any.
Essentially, it does no magic, follows the spec, and hopefully makes the debugging experience easier.
4. In rust, all tests are run in a non-deterministic order (it's random). The fact that biotin came up first is just luck, in fact, it's technically third in the order the tests are written. The only way around this is prevented by codewars, because we can't access the compiler config file (Cargo.toml). I do like the idea of it as a grand finale though... sorry!
5. Random tests are implemented. Like how your python random tests depends on your python solution, my rust tests depend on my solution to the problem. I have made sure not to leak any of the solution in the sample tests though!

Thansk for the feedback. This is now fixed!

When I was using this to play twister, it was certainly helpful!

If there's a more concrete reason to remove it, feel free to reply.

Ok thanks!

Done!

This should be fixed!