Drum Kit 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.

This is a brand-new project that should be a ton of fun to build: a drum kit! Note that the test suite may not yet work in browsers other than Chrome.

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: http://codepen.io/freeCodeCamp/pen/XpKrrW

Here is the example project with passing tests: http://codepen.io/freeCodeCamp/pen/MJyNMd

User Stories

  1. I should be able to see an outer container with a corresponding id="drum-machine" that contains all other elements.
  2. Within #drum-machine I can see an element with a corresponding id="display".
  3. Within #drum-machine I can see 9 clickable “drum pad” elements, each with a class name of "drum-pad", a unique id that describes the audio clip the drum pad will be set up to trigger, and an inner text that corresponds to one of the following keys on the keyboard: Q, `W, E, A, S. D, Z, X, C.
  4. Within each .drum-pad, there should be an HTML5 <audio> element which has a src attribute pointing to an audio clip, a class name of "clip" and an id corresponding to the inner text of its parent .drum-pad (e.g. id="Q", id="W", id="E" etc.).
  5. When I click on a .drum-pad element, the audio clip contained in its child <audio> element should be triggered.
  6. When I press the trigger key associated with each .drum-pad, the audio clip contained in its child <audio> element should be triggered (e.g. pressing the Q key should trigger the drum pad which contains the string “Q”, pressing the W key should trigger the drum pad which contains the string “W”, etc.).
  7. When a .drum-pad is triggered, a string describing the associated element is displayed as the inner text of the .display element (each string must be unique).

Feel free to choose your own sounds or pick from ours:



I’m going to start this. Is it a requirement for the new front end certificate that React or other framework be used? I can try it with or without React, whichever is more helpful.

So I got to test 5 and couldn’t pass it, because I think it tests keyboard press, although it is user story 6 where the key press should be implemented.

Awesome! I will get started on this right away! Can’t wait!!

So I couldn’t pass tests 5 and 6.
My project works as intended, but it looks like test cases don’t like my usage of Audio. I used only two wav files, but I don’t think it should be a problem. Test error messages didn’t give me any clue.

Anyway any critique welcome :slight_smile:

My styleless project: http://codepen.io/jenovs/pen/YpdmMR

@yuzu-r - all of the projects will be “implementation agnostic” when it comes to frameworks/libraries - that said, the project was built with React so it might be more helpful to make sure the tests work with another library. Either way though - anything is helpful!

@jenovs - sorry, that was a typo in that error - it should have said “when clicked” - we are testing for clicking in test 5. I will look into why the test is failing for you.

Ok, I figured out the problem with your implementation, and fixed the error message in order to hopefully make this more clear in case anyone else does the same thing. The issue is in this function:

const playKey = (key) => {
    let audioEl = document.getElementById(key);
    const audio = new Audio(audioEl.src); // << problem is here
    audio.volume = 0.2;
    audio.currentTime = 0;

With the line I pointed out, you are in effect, creating a new <audio> element which does not have the id that we are testing. We are testing that the audio element that is hard coded into the html is playing, and with this style of implementation, it actually isn’t playing. The dynamically created audio element is instead. So the fix would just be this:

const playKey = (key) => {
    let audioEl = document.getElementById(key);
    audioEl.volume = 0.2;
    audioEl.currentTime = 0;

Now the element that is hard coded into the HTML will be triggered, and all tests will pass.

This was extremely useful feedback, as I can imagine that this would be a common issue, since if we weren’t testing these, the way that you’ve done it would probably make more sense, but we need the audio elements to already exist in order to test them this way. So, I added this error message to that test:

The <audio> element with id="' + el.id + '" does not play when the ' + el.id + ' .drum-pad is clicked

Do you think seeing this would have helped it click possibly? This way it actually lets the user know that the element with that id is not playing. Let me know what you think and thanks for participating!

HTML/CSS is not my strongest suit, and I didn’t know one can trigger audio directly :flushed: When I was doing the Simon project a while ago, JS way of doing things was the one I used.

Now I did a quick google search for “play HTML audio” and first results are from w3schools and MDN :+1:, but then there is also a SO thread from 2012 which may lead someone astray :-1:

Regarding your new error message, now that I’ve read docs it seems obvious, but I’m not sure it would’ve helped me previously.

I’m going to leave my codepen as is, so it make sense to anyone reading this thread later.

All of the projects are technology-agnostic. You don’t need to use React for them if you don’t want to, but I recommend using it since that’s what most campers will use. If you need to learn some basic React first, you can work through our alpha React challenges: http://hysterical-amusement.surge.sh/

@jenovs - cool - well going out and reading docs is a major part of learning all of this, so hopefully anyone experiencing a similar problem will go out and do the same. At least we now know it wasn’t a problem with the test, just with the way it was being perceived. If it ends up being a common problem, hopefully people will get a quick answer when they ask about it here or in the chat rooms.

I’m going to leave my codepen as is, so it make sense to anyone reading this thread later.

Good idea :thumbsup:

So, I got it working moving from test to test with no problems… however then I started to finalize the sounds against their keys & make it nicer… and it looks like the tests are requiring me to have a particular order to each drum pad. In other words, I must define my pads in the order q, w, e, a, s, d, z, x, c to pass the tests.

I have an array defining all the drums’ info and if I just switch the x and c commands (my current codepen does this, line 27/30), leaving all else the same, test 6 fails with Error: Uncaught AssertionError: No audio plays when the C key is pressed : expected true to be falsy, however the correct sound does play via mouse click and keyboard press, so there is a disconnect between what the test states and the behavior a user will see.

Here’s a link to my codepen. As stated in the comments on line 27/30, all tests pass if I switch the order back to the implied but not explicitly required order listed in test 3.

This is a great starter project, very fun. I can see myself going back to this one as an extra side project even though I’m nearing completion for certification.

@yuzu-r hey, sorry to be so late in replying to this. But thanks for pointing this out, this is a good catch. I think we can fix this with a simple clarification in the user story, i.e. explicitly state the required order or the pads. I will get on this. Thanks again!

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: