This project will be part of our new Quality Assurance and Information Security section. It was designed by @JosephLivengood.
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!
User Stories
I will prevent the client from trying to guess(sniff) the MIME type.
I will prevent cross-site scripting (XSS) attacks.
I can GET /api/convert with a single parameter containing an accepted number and unit and have it converted. (Hint: Split the input by looking for the index of the first character which will mark the start of the unit)
I can convert āgalā to āLā and vice versa. (1 gal to 3.78541 L)
I can convert ālbsā to ākgā and vice versa. (1 lbs to 0.453592 kg)
I can convert āmiā to ākmā and vice versa. (1 mi to 1.60934 km)
If my unit of measurement is invalid, returned will be āinvalid unitā.
If my number is invalid, returned with will āinvalid numberā.
If both are invalid, return will be āinvalid number and unitā.
I can use fractions, decimals or both in my parameter(ie. 5, 1/2, 2.5/6), but if nothing is provided it will default to 1.
My return will consist of the initNum, initUnit, returnNum, returnUnit, and string spelling out units in format ā{initNum} {initial_Units} converts to {returnNum} {return_Units}ā with the result rounded to 5 decimals in the string.
All 16 unit tests are complete and passing.
All 5 functional tests are complete and passing.
The 16 unit tests are named with some being filled in for example. They test each function in the convertHandler(6 total) with valid/invalid/blank/ect inputs. The 5 functional tests test valid input, the 3 invalid inputs and a no number input.
Hmm, after tackling this today, I have to say that I really, really donāt like the way that these new projects are forcing users to write test suites. I aim for full test coverage with every project that I make, and already have my own go-to list of packages that let me write all kinds of tests in a manner that Iām familiar with, so I donāt want to have to write another set of tests just so that I can submit the project.
I also donāt like how restrictive these tests are in terms of project structure. I basically have to use the boiler plate to get the tests to pass, which is a bit ridiculous. Users should be able to structure their projects however they want to and not be penalised for it, providing the API endpoints all pass the appropriate tests. It would be great if the unit/functional tests were optional, especially for users who already write tests as they build the project.
@QuincyLarson, are the unit and functional tests definitely gonna be mandatory for all of the information security projects?
Thank you so much for the feedback; it does help us adjust these projects while theyāre in beta still. I can explain why it current is how it is though:
These projects are built with the main focus being testing information security and quality assurance and not specifically just back-end development in general. The lessons leading up to these projects is all about this test suite and chai assertion style that it is expecting currently. In order for us to properly test oneās project on the back to see that theyāve been able to implement the lessons learned from this section correctly in a real world way is to be very clear about what we expect and only expect that, which can unfortunately take freedom away from the user if they bring in outside knowledge outside the curriculum.
With your feedback in mind though, I will look into a way that may allow for more freedom for advanced users not using the curriculum but still technically meeting the quality assurance requirements weāre looking for in the testing!
Thanks for the reply Joseph. Yeah, I get why the projects have been set up this way, and it will benefit most users, Iām sure. Just a bit frustrating having to completely alter the way that I code in order to get the project to pass.
Would be great if you could come up with some sort of way that allows more flexibility, but I think Iām just gonna have to adapt in the meantime!
OK, so I just wrote the app again using the boiler plate and copied and pasted in parts from the app that Iād previously written. Really didnāt take long at all, and I got all tests to pass with only minor refactoring, so I think my response above might have been a bit over the topā¦
Anyway, I actually found the requirement for the āLā in litre to be capitalised to be the most troublesome partā¦ is it standard to capitalise the L for that unit?
And as I said, writing the tests didnāt take long at all. The only thing Iād quite like to see changed would be to add the option of using Chaiās expect assertion style. Any plans to incorporate that into the curriculum at any point? I think itās definitely easier to grasp than assert for newcomers to testing. Hope the feedback helps in some way.
So we can definitely add the support for expect in time- but Im thrilled you were able to get them working with assert!
The capital L for Liter(/litre) is actually something I never thought about possibly being different in different parts of the world. In North America we learn its absolutely wrong to ever leave liter abbreviation lowercase in any situation ever!.. But looking into it, I see in Europe its okay either way! Iāll look into either possibly removing the requirement or clarifying why its there (if we want to leave that complexity)
Thank you so much for the continued feedback and support to help us make these projects better!
The demo project is broken, all the code is missing from Glitch. I tried contacting @JosephLivengood here and on GitHub, but he was last seen here on Feb 21, '17. I guess he is not involved with FCC anymore?
I donāt know if it is possible to take over his demo project just like that and restore the code. If we make a new one, the links on the challenge page, here in this thread and possibly on the Tester need to be updated. The Links on the Tester all still use the old gomix links and should be updated anyway.
Maybe someone in charge can look into this? Or someone is still in contact with @JosephLivengood ?
Itās my last certification and I am trying to complete this project from since 1 month, itās getting too tough and somehow irritating for me to complete it. If I try to fulfill functional and unit test, then it doesnāt fulfill my actual tests, if i fulfill my actual tests, the error occurs in fulfilling functional and unit tests. Kindly help it out