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.
Right now these are on CodePen, but we will move them over to FreeCodeCamp’s challenge platform once we have multi-file editing (for more on this, watch this video).
Here’s the Pomodoro Clock challenge:
Working example - wait for tests to run
Empty pen with test suite - fork it
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!
@P1xt I’ve only given the first one a quick glance (and it is quite awesome for the record), and at a very quick inspection, it looks like it could pass all tests except for the ones requiring increment and decrement buttons rather than sliders as this pen has (except for the mm:ss format for time which could be remedied really easily and would not affect the integrity of this application). But yes, this is good feedback, and we can possibly work around this, which is why we are posting them this way before actually pushing them as replacements to the current versions. I will put some thought into this and see what we can do!
EDIT: and you are right, the second one would not come close to passing, on a good day or a bad. This is def something to consider. Though by all accounts, I would venture to believe that both of these apps were created by folks with FAR more experience than the typical camper who is just beginning to learn. Not sure what that counts for, but these tests may not limit the average camper in nearly the same way.
EDIT #2: It would seem that I am wrong based on Jeremy’s CodePen tagline:
I am currently a student at Free Code Camp, with the goal of finding a job as a junior developer!
Yet I cant think of a single set of ubiquitous user stories that could test both this project, and the example, and get passing results for each. Any ideas @P1xt?
@QuincyLarson do we consider these edge cases and proceed as planned?
I’m all for creativity when it comes to building the projects (the only two that I have done only resemble the examples superficially and likely wouldn’t pass automated testing either).
But, I think the good thing about requiring campers that want their projects to pass the tests is that they are now required to be developed to, and pass, a specification set by an external agency. Which is a fact of life for many (most!) programmers.
So I don’t think it’s a bad thing that the creative projects wouldn’t pass the tests. After all, if a designer and client come to you with a site specification and you deliver something completely different, it would fail their “test” simply on inspection.
If a camper was feeling adventurous, the version made to pass the tests could be thought of as their prototype … once that’s done, they could fork the pen and make a more creative version.
Anyway, just one perspective.
@p1xt Our intention is to only dictate form to the extent necessary to test functionality. Perhaps later you can help us refactor these tests to allow for more flexibility.
These tests will run anywhere - they are not CodePen specific. So you could pull the test suite in with a
<script> element and deploy it to GitHub pages, Heroku, or wherever you want.
@p1xt I agree that campers should get experience deploying to real world servers, but they need to learn to walk before they can learn to run. These projects - and in fact the entire first 1,200 hours of Free Code Camp’s curriculum - are a slow, controlled dive into a massive ocean of skills that will take years to fully acquire.
We are making all of these as implementation-agnostic as possible. Campers can always export their projects to other places and build versions that completely deviate from our user stories once they’ve first complied with the requirements (which they will be expected to do on the job, anyway).
Cooked up a pomodoro clock. Can’t seem to pass the last 5 tests though.
Correct me if I’m wrong, but Pomodoro tests starting with test #11 utilizes the reset button, but no tests prior to that checks implementation of the Reset button.
Actually no tests check the functionality of the Reset button
So if a camper is doing implementation step by step (test by test) he won’t pass tests which are resetting timer.
@jenovs good point - that can be easily fixed. Right now the tests up to test #11 are designed to run regardless of whether or not a reset button is implemented yet, but of course, what the reset button should do, clearly needs to be defined. Thanks.
Cooked up a pomodoro clock. Can’t seem to pass the last 5 tests though.
Hmmm… I didn’t write this portion of the test suite, so I am not sure why they are not passing, although they look like they should be passing to me. I will have to let @Weezlo chime in on this one. Thanks for helping out and identifying this!
What happens if this ends up creating more roadblocks that it removes? It’s going to be pretty difficult to write a test suite that can account for all of the diversity of implementations that 200k + campers can come up with for any given project. Personally, I think that prior to the front end certification, that diversity and freedom is much more important than that projects pass a suite of tests.
Allowing newer campers to test the waters on the edges of their knowledge and stretching to add a cool idea they had to a project or even outright implementing an app in a completely different way is a lot more valuable than putting a cage up that says “you must operate within these boundaries”. Sure, there will come a time when developers have to work to a specification and the ability to do that is a valuable skill to learn, but I’d argue that these test suites would be much more appropriate after the front end section. Of course, at that point, campers should probably start thinking about learning how to write their own tests.
I guess mark me as skeptical that this is a valuable addition and isn’t actually harmful to campers’ learning and motivation to keep working on a project because some test is (justifiably or erroneously) blocking their forward progress.
because some test is (justifiably or erroneously) blocking their forward progress.
I do hear what you’re saying, but on this point, isn’t that what the community is for? The percentage of campers that don’t ask questions when they get stuck has got to be pretty small, and as more and more campers successfully complete these projects, the more and more help will be available to figure out how to get past a certain test. It’s really no different than getting all tests to pass on an algorithm challenge or something.
Either way, hopefully we can hear from more folks and see what more campers think. It’s good that we’re getting a good discussion going.
I’d argue entirely the opposite here. An algorithm can be tested for a very specific output. I want the reverse a string function to return the str variable but reversed. You’re testing input and output.
Testing project applications aren’t so simple. What if I decide for my pomodoro timer that I want it to operate entirely differently from the what the tests are looking for? Is it not still a pomodoro timer? Where do you draw the line between what is and is not permissible? What if I like the general idea of the project, but determine that it would actually be better for my own personal use if there was no reset button (I don’t know why that might be the case, but this is an example). So are we going to say to that person:
- “No, you can’t pass this project because you didn’t include a reset button.”
- “No, you can’t pass because you didn’t include an animation.”
- “No, you can’t pass because you included this thing that we disallow.”
I’d argue that allowing maximum freedom is much more valuable than having campers code to a strict test suite that will tell them they are “wrong” when what they should be doing with the early projects is learning what they are capable of doing with code.
@QuincyLarson, would it be possible to keep somewhere in the map (maybe as optional) the current (more polished) challenges? It personally, helped me improve a lot, to try to make my projects look like these challenges.
@matty22 @P1xt - I can’t say that I fully disagree with either argument, but this is a difficult problem to come up with any one-size-fits-all solution to, because as was mentioned somewhere above, as FCC continues to grow, the task of ensuring campers actually fulfilled the requirements of these projects becomes incredibly difficult without something like this, and of course we need a way to validate that when a camper gets a cert that they actually earned it. So I don’t know…
And @P1xt, by no means was I taking this as a criticism of the work, but I thank you for saying that. I’m simply playing devil’s advocate here because I see merit in both sides of the argument and it is def something that needs to be discussed.
Personally, I think that prior to the front end certification, that diversity and freedom is much more important than that projects pass a suite of tests.
@matty22 one other thing that should be pointed out in response to this, is that the certs will be organized in a different way than they are now by the time that this is fully deployed - this project will actually be a part of the Front End Libraries cert, which comes after JS Algos & Data Structures, which comes after Responsive Web Design - so there will have been quite a bit of work done at this point by any camper that has chosen the recommended path and gone in order. The test suites that test the Responsive Web Design projects are MUCH easier.
I agree with at least one other here that TEACHING testing is far more valuable than writing a front end app that passes string of tests, unless those tests are so straightforward that it will not limit creativity.
I can see in some aspects the test suite could guide someone to make the project (must have a dvi with an ID of “timer” ) hey…there’s a good way to start. “Must have two buttons, one for increment, one for decrement”.
it’s like the test suite is breaking up the project into small bite sized pieces. But then it’s not acting as a test suite, it’s acting as a “Build” suite. The project is already broken up into small compoenents for the new coder. I’m not sure if this is good or bad, i’d say it’s ONE option that could be pursued.
How are the testing suites different from the user stories in terms of a functioning final project? If the project meets the user stories than it’s adequate, right?
The testing suite could/should be applied in a curriculum section specific for teaching testing, not just making tests pass.
( I am on the full stack projects and still have little idea how to write tests).
@P1xt Cool, glad your internet is back up and running! I know I would be freaking out if mine was down.
To answer your questions:
- Feel free to delete the HTML comments if you don’t need to refer back to them for anything. Or change them to Jade comments (
//- for line comments
// for block).
- Because every other id selector refers to a single phrase, e.g. “Break Length”: id=“break-length”, whereas start_stop actually refers to 2 separate actions. If it’s confusing, could always be changed.
- Adjusted RegEx to allow for mm:ss, mm: ss, mm : ss, mm :ss (allows 0 or 1 space on either side of the colon).
- The tests do not check the contents of those elements for that very reason, in fact, the example which passes all the tests uses FA icons. We could change the copy here to say that it should INDICATE a + or - sign/action.
- Working on this - another camper had the same result.
- Do you use Gitter? It would make this back and forth much easier. Everything that’s missing from that picture is a FA icon… what browser are you running? I’m guessing Chrome if the tests are running…
- Not sure why that’s happening - it shouldn’t be, and is working well on my end in Chrome. Will have to look into this.
- Got it. Updated User Stories for these 2 (should be more clear by being less specific):
- I can see two clickable elements with corresponding IDs: id=“break-decrement” and id=“session-decrement”.
- I can see two clickable elements with corresponding IDs: id=“break-increment” and id=“session-increment”.
If you have any other questions, or if anyone does for that matter, and they are specific to your experience in testing these, feel free to message me on Gitter. If it’s something that will benefit everyone, of course, keep em’ coming here. Thanks!
A quick note on testing - this has been a common criticism of our curriculum from the beginning, and we are remedying this.
Our expanded curriculum will involve writing lots of tests, and at least 5 of the projects will involve you writing both unit and functional tests.
@QuincyLarson @Weezlo I’ve taken a peek at both @P1xt and @Quickz’s implementations of this project - they’ve both used
setTimeout() while I used
setInterval(). I know we tried to account for this, but it looks like the last 5 tests are failing in both of their cases because
clearTimeout does not seem to be working to stop time from running on our sped up “global hacks” of both functions, hence the error message about
timeout of 5000ms exceeded? Just a hypothesis at this point…
@P1xt: http://codepen.io/P1xt/pen/ObWZgZ (see P1xt’s disclaimer )
Thanks to both campers for being our guinea pigs on these! The feedback and analyses we can do from these will be quite useful!
I did a pragmatic programming course before finding FCC and they implemented testing from the 2nd lesson onward, it made it really easy to develop, but it was (I think) specific for ruby/rails.
It wasn’t pretty fun to code to the tests and then just have it work the first time I opened the browser!