Markdown Editor Project with testable user stories - Guinea Pigs needed 🐹

Markdown Editor Project with testable user stories - Guinea Pigs needed 🐹


As you may have heard, @no-stack-dub-sack and @Weezlo have been hard at work building projects with testable user stories. We are looking for a few volunteers to attempt to build these based on their automated tests.

The goal is for campers to be able to build these projects step by step following user stories. This will make the projects less intimidating and more fun. Oh, and don’t worry - we’ll still have plenty of optional projects where we don’t provide you with any tests. And if you’ve previously built these projects, you don’t need to build them again.

If you’re interested in attempting this, please reply to the thread and let us know you’ve started it. The more people who want to build this, the better, as we can start gathering feedback.

Thanks, and happy coding!

Here is the blank pen for campers to fork:

Here is the example project with passing tests:

Here are the user stories for campers to reference:

  1. I can see a <textarea> element with corresponding id="editor".
  2. I can see an element with corresponding id="preview".
  3. When I enter text into the #editor element, the #preview element is updated as I type to display the content of the textarea.
  4. When I enter GitHub flavored markdown into the #editor element, the text is rendered as HTML to #preview as I type (Hint: You don’t need to parse Markdown yourself - you can import the Marked library for this:
  5. When my markdown previewer first loads, the #editor field should contain valid default markdown that provides a brief description of the project and demonstrates the previewer’s capabilities.
  6. When my markdown previewer first loads, the default text in the #editor field should contain valid markdown that represents at least one of each of the following elements: a header (H1 size), a sub header (H2 size), a link, inline code, a code block, a list item, a blockquote, an image, and bolded text.
  7. When my markdown previewer first loads, the default markdown in the #editor field should be rendered as HTML in the #preview element.


Just made one with absolutely no styling…

Bug in the test suite: Test #8 passes even though my links don’t open in new tabs.


Excellent work. Thank you for the feedback.

Did you encounter any other difficulties or ambiguities building this?

@no-stack-dub-sack do you know what might be causing test #8 to pass without links that open in new tabs?


Well, at one point I somehow had the wrong test suite selected, and it took me a while to find out why the tests weren’t running. The test suite dropdown menu could use a larger font size, I think. Some kind of warning that pops up when you choose the wrong test suite would be helpful, too.


If you can figure out how we would be able to warn campers about the wrong test suite, that would indeed be a big improvement. Do you have any ideas? If they don’t tell us what they’re working on, it would be hard to pick the right test suite for them based purely on their initial code.

And thanks for the feedback on the font size. I’m mentioning @no-stack-dub-sack here to get his opinion on this.


You’re welcome :slight_smile: I can’t think of any good solutions, given CodePen’s limitations. Maybe the most practical solution is to add a comment in the Fork Me template, like “// MAKE SURE TO CHOOSE THE CORRECT TEST SUITE!!!”


@QuincyLarson @leonfeng Hey guys, sorry, I’m a bit behind on my notifications here…

As for test 8 - yes, test 8 (and test 9) will pass no matter what, as they are marked OPTIONAL BONUS: ... just to let campers know that there is an extra challenge there if they’d like to undertake it.

As for the wrong test suite issue - it’s not so much a limitation of codepen, but a limitation of the concept of the project in general. Without adding a hard coded “test harness” variable to the test suite “fork me” pen, there is no way to detect what a user is attempting to build at this point. Campers may encounter this issue, but upon reading the user stories and checking out the two where the app notifies what you are working on, it should be pretty easily overcome (as it seems like it was for you @leonfeng). Like with many things, there’s a slight learning curve (very slight I hope), but once the problem is realized, it’s unlikely to happen again. I.E. this is a first-timers issue, and once someone gets used to working with the test suite, it should be a non-issue. That said - your suggestion is a good one, and I’ll do that now!


Thanks for participating in the QA process @leonfeng, and glad to see you were able to get all of the tests to pass!


@leonfeng I’m also very happy you were able to get this working with React!!! It was exceedingly difficult for me to figure out how to programmatically trigger a change event on a textarea in a React app, so glad it is actually working on someone else’s implementation (its not as simple a task as it seems :wink:)


@no-stack-dub-sack I actually attempted this particular challenge last year, so it was not too hard once I warmed up on React docs :wink: And you probably get this a lot, but this testable user stories thing is genius! Now I totally get test-driven development!


@leonfeng great! Glad to hear you enjoyed the process! That’s the effect we were hoping it would have :smile: I wish I could take credit for the idea, but @QuincyLarson & @Weezlo came up with the concept, I just helped a lot with the implementation, but glad you are loving it either way!!!


Just built a Markdown Editor with Vue.js and tests 3, 4, and 7 are failing.


@christophherr hmmmm… interesting. Thanks for reporting this. I’ve opened an issue on the repo here.

Unfortunately, I’m not sure there’s a whole lot that can be done about this, which is a problem. Partly because I have no idea how Vue.js works, I’m going to tie in some other folks on the issue thread.

Thanks for your feedback on this one!


Thanks for your feedback so far, everyone!

I’m thrilled to announce that our testable challenges now feature a link you can click to report a bug or submit feedback.

I’m closing this topic. We can continue discussing specific issues as they come up over on the testable-projects-fcc repo. Happy coding and QA’ing! :slight_smile: