campers hardcoding solutions for final projects

[ilenia-magoni]

The JavaScript final projects have an issue, I don't know if how they are written, there are really specific user stories and no general one. Anyway, it's scarely common that campers try hardcoding the solutions. Should we try to write tests that discourage this?

Or, alternatively, more generic userstories that explain the thing better?
Like, we have

When the #search-input element contains the value Red and the #search-button element is clicked, an alert should appear with the text "Pokémon not found"

But there isn't a more generic user story that is explicit on the requirement.

When the #search-input element contains a value that is not a Pokémon name...

[gikf]

One option could be trying to join the two, when that's possible. Taking the same example as above:

• One specific user story, using in test the exact values as in the user story.

When the #search-input element contains the value Red and the #search-button element is clicked, an alert should appear with the text "Pokémon not found"

• One generic user story, where test should be essentially the same as in the specific case, but using different value to search.

When searched text is not a Pokémon name, an alert should appear with the text "Pokémon not found"

[ilenia-magoni]

note, it's not only an issue for the Pokémon search app, I have seen this for the palindrome checker and the roman numeral converter too

[jeremylt]

Yeah, campers seem to be struggling really hard with how to create original functions that meet the user story outcomes here.

This isn't wholly surprising, as up to the point where they get to the first project (and some of the later projects) they no longer encounter places where we ask them to generate small functions to accomplish a task. I think the fix is twofold. One, we need to test for and prohibit testing to the solutions. Second, we need to give campers smaller opportunities to build single functions from scratch that meet a tested objective - maybe something that looks like https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures/#basic-javascript 🙃

[a2937]

Yeah something like that basic JavaScript path would be great before we get to the html/css/javascript projects considering their bulky size.

As for the prohibiting testing to the solutions, I like the idea of a hidden test with additional inputs the code is tested against rather making all the tests generic. Some specific actual tests are nice so we can run the code right there and see a response in the console. If they're not coding just towards the solution, then those additional inputs will work and everything will be fine.

[jdwilkin4]

@a2937 and @jeremylt

Yeah something like that basic JavaScript path would be great before we get to the html/css/javascript projects considering their bulky size.

that is why the new intro project is being created

freeCodeCamp/CurriculumExpansion#374

[jdwilkin4]

I vote for this approach

One option could be trying to join the two, when that's possible.

A combination of generic and specific user stories would be ideal

[jeremylt]

That's a good project but it's one project though. I'm proposing that we give back the campers the opportunities to do many small one off functions to practice open ended problem solving before they get to the certification projects.

[jdwilkin4]

I'm proposing that we give back the campers the opportunities to do many small one off functions to practice open ended problem solving before they get to the certification projects.

Yeah, I see where you are coming from.

A new GitHub issue would have to be opened for this particular discussion and the rest of the JS team would need to weigh in 👍

[gikf]

Generic tests could also add some randomness to the equation. Either by picking test case from a specific set test cases/results, or a more generated test case. For example:

Pokémon Search App:

• Test picks from few valid Pokémon names or IDs, which will be used in test.
• Test checking invalid name or ID could use randomly generated value.

Roman Numeral Converter:

• Randomizing number below 0, which is used to test the appropriate behavior.

Palindrome Checker:

• Generating strings that fulfills generic test requirements, for example: generating random lowercase word (just letters).

[ilenia-magoni]

that last one, it can be also used to test palindromes: generate 4 letters, reverse the order and concat the two together: voilá a palindrome