Freecodecamp: [beta] Using the Flex-direction Property to Make a Row - Any value accepted

[Sirjustin]

Challenge using-the-flexdirection-property-to-make-a-row has an issue.
User Agent is: Mozilla/5.0 (X11; CrOS x86_64 8872.76.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.105 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
Almost any value entered into box container will pass including column and any word-direction

<style>
  #box-container {
    display: flex;
 fart:column;

  }
  #box-1 {

    background-color: dodgerblue;
    width: 500px;
    height: 500px;
  }

  #box-2 {
    background-color: orangered;
    width: 500px;
    height: 500px;
  }
</style>

<div id="box-container">
  <div id="box-1"></div>
  <div id="box-2"></div>
</div>

[ajain17]

Can confirm this on staging. Although if we want to disallow everything else except what's mentioned in the challenge, we would need better regex assertions in all of these tests. I verified that all of the challenges pass with bogus values as long as the correct code is there.

[HKuz]

@Sirjustin :rofl: - I think we should petition the W3 consortium to make fart: column; a valid Flexbox option. This challenge was passing on Beta because when display: flex is on a container, it automatically places flex-direction to row since that's the default. We recently merged a PR (#12887) that changes this challenge to use row-reverse instead, and fixed a couple other challenges where the default allowed anything to pass.

@ajain17 - I just ran the latest staging branch locally, which includes your changes from PR #12887 and this is fixed. The Beta site is being updated with staging around every 1-2 days, so that will be reflected soon. 😄

I'm going to close this issue as fixed on staging - @Sirjustin thanks for the help with QA on the new challenges!

[ajain17]

@HKuz I ran the staging branch locally too, and could see the issue being there. This issue is there in all flex challenges since we only check that the correct property is there, we don't check that no bogus properties are present. The test passes with invalid code present. Please correct me if I'm wrong. Thanks.

[HKuz]

Okay, I see what you're saying. Most of the tests, especially on the new challenges, are only checking that the camper did what was instructed. They don't also check that there were no additional changes to the code (that would be a hard task).

I can re-open this for discussion about the invalid syntax being ignored. @freeCodeCamp/moderators - is it okay that invalid propertyName: values; are being ignored and the tests run okay (and pass, as long as the camper also followed the instructions)? Or should invalid syntax (with or without the correct solution, too) trigger the "Keep trying" / "Something went wrong" toast?

[ajain17]

@HKuz Like I mentioned above, if we want to disallow everything else except what's mentioned in the challenge, we would need better regex assertions in all of these tests. Many of our tests allow bogus properties to be added as long as the correct code is there.

[Greenheart]

1:

Ideally, we'd verify their code and make sure it's completely correct. If we only have like 10-15 lines of code to test, this could be doable by matching what we expect and not allowing anything else.

Basically, we know that #box1 needs N properties changed to pass. So we test for N pairs of prop: val; for this element, only matching the pairs we actually want. If anything else is found, the tests should fail since the code isn't "valid" at that point.

This way, we could be sure that all code campers enter is valid, and that they don't add additional things that would break the code if it's run in the real world.

2:

Alternatively, we only check for the code actually needed to complete the challenge. I'm pretty sure this is how most challenges reason about tests.

• If we provide tests that ensure people can complete the challenges if writing valid code, those who want to learn to write valid code will do so - and pass their challenges.
• Those who write invalid code by mistake will not pass challenges - and won't learn the wrong things.
• Finally, those who add random code either won't pass challenges (if they don't have a solution working without the random parts) or, will still pass (if they already solved the challenge).
• Those who deliberately add random code could either pass or fail.
  
  
  
  • If they fulfill all requirements for the challenge, their code is valid and they should pass - even if they add additional junk code (without breaking any test cases), because they've already proved that they understood the challenge.
  
  
  • If they don't meet all requirements and add junk code - they fail.
  
  

The second approach allows those who want to learn to do so, while saving time for us that we better could use to provide motivated students with additional content.

I'm leaning towards solution 2 :blush:

[HKuz]

@Greenheart - thanks for that amazing write-up comparing options 😄 👍 I'm also leaning towards point 2. There are many ways folks can add wrong or unnecessary code, but there (should be) only one right way to pass the challenge (and prove they understand the concept). There's also that old known issue where the cursor in the code editor can randomly jump around while you're typing - I've been a victim of it's oddball ways and ended up with random junk code in places it shouldn't be. I'm afraid if we make strict tests that code hasn't changed, and someone doesn't notice the cursor thing, they'll wonder why their code won't pass.

[HKuz]

I think we've left this issue open long enough for other folks to weigh in. I'm going to close it, but if anyone wants to add to the discussion, feel free to re-open 👍

Thanks all 🎉 🍀

[BackinGehenna]

`

`