JavaScript/Mocha Project: Rooster Regulation

[mreed4]

This is not a “Help I got stuck on step x of the project” problem. This is not a “I did y and my code still won’t work, why?” problem. This is not a “I don’t understand the project” problem.

This is a question seeking clarification on whether or not my solution is viable, and if not, why not.

The project in question is to write a test suite for code pre-written by Codecademy. In order to complete the project I had to watch the helper video.

In the helper video, “Matt” describes that the Exercise part of the test for RangeError is–in this case–part of the Verify part of the same test. Matt deletes the Exercise part. Per Matt, putting the Exercise part of the test in its own section will “get really messy pretty quickly”.

At this point in the video, his code looks as follows. I understand why it works.

it("throws an error if passed a number less than 0", () => {
  // Setup
  let inputNumber = -1;
  let expected = RangeError;

  // Verify
  assert.throws(() => {
    Rooster.timeAtDawn(inputNumber); // Exercise
  }, expected);
});

However, as seen below, I refactored his code after watching the video so that it is formatted like the other tests. This also works, at least in the sense that all tests pass. I understand why it works. I understand (or believe) that both versions essentially do the same thing.

it("throws an error if passed a number less than 0", () => {
  // Setup
  let inputNumber = -1;
  let expected = RangeError;

  // Exercise
  const actual = () => {
    Rooster.timeAtDawn(inputNumber);
  }

  // Verify
  assert.throws(actual, expected);
});

To me, what he did is messy. No disrespect, Matt …

My question is/are,

1. WHY will putting Execute in its own section get really messy?
2. Is the “messy” comment his opinion?
3. Is what he did “best practices”? If so, why?
4. Was the video released before some feature became available in JavaScript?
5. Is my refactor somehow wrong, or “not actually testing the code”?

[jamah_ha]

I agree with this - I think when working through the exercise it would have been more helpful for the demonstration to keep to the structure that we’ve been shown, particularly as it’s been emphasised quite strongly that this makes things more maintainable and expressive (or less ‘messy’). I also think your solution makes more sense in that context, and I don’t think there’s anything wrong with it functionally, though I could of course be wrong as I’m very new to the topic.

By my understanding of the assert.throws() method, the first argument you pass in is a function, which you represent in your example by declaring it separately with the variable ‘actual.’ Matt does this all in one assert.throws() call by calling that function within the method, which is fine and maybe slightly shorter, but it isn’t as clear or expressive, because it’s hard to see at first glance that this represents the actual response. I think perhaps this comes down to experience and preference, along with his familiarity with the assert.throws() method, but in the context of the lesson (and again, being expressive/understandable), I actually prefer your approach.

[mreed4]

It sounds like it is a subjective thing–perhaps also something that depends on employer preference. That is, one employer prefers one way, where another employer prefers the other way. Neither are “wrong” per se.

This is an example of something I have come to learn is one of the “soft skills” a new developer must learn. So long as you have the technical knowledge, you should be able to translate that knowledge to the format your employer prefers or requires.