Metric Imperial Conversion Project with testable user stories - Guinea Pigs needed 🐹

Metric Imperial Conversion Project with testable user stories - Guinea Pigs needed 🐹
0

#1

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.

Passing prototype built on boilerplate: https://gomix.com/#!/project/hard-twilight
Boilerplate: https://gomix.com/#!/project/fcc-convert
Tester(ISQA_2-Metric/Imp Converter): https://pricey-hugger.gomix.me/


#2

Good morning,
I have completed all user stories except the unit test and functional tests. They keep displaying

TypeError: Cannot read property ‘assertions’ of undefined

when the tests I created are correct


#3

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?


#4

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!


#5

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!


#6

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.


#7

@tom-p-uk

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!


#8

Demo ==> https://brusbilis.com/freecodecamp/6-backEnd/metric/metric.html

Code ==> https://github.com/brusbilis/freeCodeCamp/tree/master/6-backEnd/metric

I made input data not case sensitive to avoid misunderstandings

Backend is made with Golang instead of node

Security requirements are implemented in nginx

Using https://pricey-hugger.glitch.me/ only pass the 5th test


#9

Hi guys, could you look on https://glitch.com/edit/#!/metric-imperial-converter-fcc, please.

It looks that everything is fine, but it fails on tests 11-16 with error TypeError: Cannot read property 'assertions' of undefined.


#10

I am having this problem too. Does anyone have any insight to offer?

UPDATE: For anyone else having this problem, in your .env file set NODE_ENV=test. That solved it for me.


#11

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 ?


#12

@jeremylshepherd Thank you! That works