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).
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.
@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.
@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).
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!
@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ā¦
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.
)