# FCC Challenge: JS Algorithm: Telephone Number Validator

I learned a lot in this challenge. It’s important to account for the possible cases in the test phase instead of while coding. What I’m saying is that coding the solution is a different session from coming up with the test cases, this is the importance of QA Test Automation. Because, it’s easy to miss special cases when you approach the solution directly.

My approach here is to just match all the test cases instead of thinking my own test cases in my head. This is the challenge where I started to use that approach instead of making up cases while coding. I used to do the my-own-test approach just because I was thinking that the test cases might’ve missed some possible real-world scenarios (this is slightly different from security issues).

In short, I learned to trust the test cases, and focus my time on coming up with the solution instead of burning my time through imagining “troll inputs” and how to troll-proof the functions.

This is my solution developing from FCC’s test cases. Given that I’m not American to know the acceptable inputs.

"Solution
``````function telephoneCheck(str) {
let validCountryCode=true;
let countryCode;

// copy country code from original number
countryCode = str.slice(0,2);

// if telno. has space, compare country codes
if(typeof str.split(" ")[1]!="undefined"){
// if countrycode is 1 and separated by space or parentheses. its valid
validCountryCode = countryCode=="1 "||countryCode=="1("?true:false;
}

// strip away country code from original number for accurate regex
if(countryCode=="1("){
str=str.slice(1);
}
else if(countryCode=="1 "){
str=str.slice(2);
}

// regex for ff. special cases
// 555-555-5555 | 5555555555 | (555)555-5555 | (555) 555-5555 | 555 555 5555
let regex = /^\d{3}-{1}\d{3}-{1}\d{4}\$|^\d{3}\d{3}\d{4}\$|^[(]\d{3}[)]\s{0,1}\d{3}-\d{4}\$|^\d{3}\s\d{3}\s\d{4}\$/;
if(regex.test(str)){return validCountryCode&&true;}

return false;
}
telephoneCheck("(555)555-5555");

``````

Right. I mean, I think in terms of completing this specific challenge you can write to the tests and not worry about other edge cases.

In the real world, I probably would want to. If I had to write a phone number validator function, I would probably write the test cases first. This is a principle of TDD, or Test Driven Development. I don’t always do something like this, but for simple, pure functions, it makes sense to me.

Of course, you are sometimes given the boundaries of how a function should work, but with something this simple, or at least straightforward, it is not unreasonable that you would just figure it out yourself. In fact, you might even just be given a task to design a “create an account” form and just have basic user stories for that and have to figure out the validation all on your own. In this case, I’d want to come up with as many edge cases as I could because I am designing that function and it may get used in other places.

But if you’re given the test parameters like this, you could also argue that you don’t want to “gold plate” it, build in functionality that wasn’t originally requested. Sometimes it’s hard to know where the line is.