re: How to approach solving a challenge during a coding interview VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Hey John nice to hear from you. Yes will certainly do a follow up and just today someone was asking testing during a lecture. Will address it aASA...

Thanks Ady, I will await your future post on the subject, but in the meantime, I can see a way that fizzBuzz could be tested although it would need some modification from it's present form.

Great please do share your solution if you do not mind. As I mentioned the one proposed is a personal preference and there are many other ways to solve for it.
Testing for it should also be pretty straightforward. If console.log is an issue we could build and return an array of outputs in the function and write a test for small subsets.

That sounds more interesting than the approach I was thinking of, I would prefer to follow your lead, so could you expand on your idea of an array of outputs and testing small subsets?

Hello John, below I'm adding what I would consider a more 'unit testable' solution to the FizzBuzz challenge.

It is important to note that this steps out of the context of solving a challenge during a coding interview and jumps into the refining and 'make ready for prod' exercises.

Like John Papa says in his talk 'Readable Code' - "Nothing start readable. Write dirty code, then clean it".

I would argue the same for testable in the context of a coding exercise.

const output = arrayToString(createArrayFromRange(1, 100).map(fizzBuzz));

console.log(output);

function createArrayFromRange(start = 1, end = 1, increments = 1) {
    return [start, ...Array.from({ length: end - 1 }).map(() => start += increments)];
}

function arrayToString(arr = [], separator = ', ') {
    return arr.join(separator);
}

function fizzBuzz(number) {
    let output = ((number % 3) ? '' : 'Fizz');
    output += ((number % 5) ? '' : 'Buzz');
    return output || number;
}

The above provides you functions as very isolated units making them easily testable. Now this does not address writing tests for void functions or methods. Depending on the suite you use, there might be different strategies such as using spy if you write with Jasmine.

That should be for an entire different post altogether :) Let me know what you think.

Cheers

Yep, looks pretty good to me. Now it's returning a value it's testable.

Just for some added value I've included a small function called should to test it with and, of course, it passes...


// small unit testing function follows...
const eq = (a, b) => a === b
// curried should function.
const should = fn => (t, s) => (fn(t, s)) ? 'passed' : 'failed'
const shouldEq = should(eq)

const fb1To15 = "1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, FizzBuzz"

// Test fizzBuzz first 15 terms.
console.log(
  `Assert: First 15 terms of FizzBuzz should equal:
    1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, FizzBuzz:
    Test: ${shouldEq( arrayToString(createArrayFromRange(1, 15).map(fizzBuzz)), fb1To15 )}
  `
)
/*
 => Assert: First 15 terms of FizzBuzz should equal:
    1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, FizzBuzz:
    Test: passed
*/

// End test.

const output = arrayToString(createArrayFromRange(1, 100).map(fizzBuzz));
console.log(output);

function createArrayFromRange(start = 1, end = 1, increments = 1) {
  return [start, ...Array.from({ length: end - 1 }).map(() => start += increments)];
}

function arrayToString(arr = [], separator = ', ') {
  return arr.join(separator);
}

function fizzBuzz(number) {
  let output = ((number % 3) ? '' : 'Fizz');
  output += ((number % 5) ? '' : 'Buzz');
  return output || number;
}

My only other suggestion is you could do the following to get back to your original fizzBuzz implementation.


function FizzBuzz(s = 1, e = 100) {
  return arrayToString(createArrayFromRange(s, e).map(fizzBuzz));
}

Cheers Ady ... It's just gone midnight here, so better get some sleep.

Bye for now.

As always great contributions John. I really like the idea of a small assertion library to quickly test code inline and not having to rely on a full blown testing suite. I have in fact started a project on github called dotLog to do just that. I haven't had the chance to do more on it lately but it would be fun to have you contribute to it and maybe have a few other people do.
Good night for now, let me know what you think about that in whatever your AM is.
Cheers :)

Yes, when you don't want the overhead of a full blown test suite a quick and dirty should function will do. I know it pretty minimal, but, sometimes, less is best!

I had a quick look at your dotLog code, but have'nt got much time this morning to figure it out. To aid my understanding, could you update the Readme with an example of usage, eg.


dotLog.describe()
// takes in a String and an Array of Objects?
// What properties does each object have?
// etc, etc.

I don't want to guess at it.

Also, I have'nt played about much with the finer points of console.log, but I think the syntax that you use in dotLog will only work in the browser, but not when used with node. However, node's console.log will do colour changes, but I think the syntax is a little different. This would be worth exploring to make dotLog useable in the browser and node. Correct me if I'm writing crap here.

I will take another look this evening and otherwise wait for the Readme update. Yeh! Could be fun, but, as you know, I do have a tendency towards a functional style of JS? But, whatever, I do love JS

Cheers Ady.

Yes you are absolutely right - you should not have to try to figure it out. I need to do an initial clean up and set it in a way that it's intuitive and easy to contribute.
I don't mind the functional approach 'au contraire', I have been writing a lot like that lately. Point free composition is an absolute gem when done right. I just want to steer away from getting into dogma stands with FP vs OOP. I really think they can be complementary.
I've learned a lot from your style of writing and started implementing some of it. I could not handle professor Frisbee though, my head was spinning with that voice after a while lol.
Anyhow I'll clean up the dotLog project and ping you as soon as it's ready. Probably sometimes next week since this one is going to be crazy on my side.
Cheers :)

Yes, absolutely with you on that; fp, oop => it's all JS to me!

Yes, again Prof. Frisbee (aka Brian Lonsdorf) I've watched a number of his talks on youtube and I think he is a great guy to learn from, but making something funny (as he did with Prof. Frisbee) can always risk a "Marmite" response... you either love it or hate it!

No rush on the dotLog project... it's for fun; no deadlines required!

So long for now Ady

Hey Ady,

I've been investigating dotLog. I just wanted to let you know how much I like it. dotLog is minimal, that's nice; personally, I would keep it that way. Start a new project if you want more features. Here's what I've had time to suss so far...


const concatS = add = (a, b) => a + b

dotLog.describe("function add", [
  { 
    label: "add is a function",
    rule: ( typeof add === 'function')
  },
  {
    label: "add takes two arguments",
    rule: (add.length === 2)
  },
  { 
    label: "add - Adds two numbers together; add(5, 4) returns 9",
    rule: (add(5, 4) === 9)
  },
  {
    label: "Add should return a value of type number, if passed two numbers",
    rule: (typeof add(5, 4) === 'number')
  }
])

dotLog.describe("function concatS", [
  { 
    label: "concatS is a function",
    rule: ( typeof concatS === 'function')
  },
  {
    label: "concatS takes two arguments",
    rule: (concatS.length === 2)
  },
  { 
    label: "concats two strings together; concatS('Super', 'man') returns 'Superman'",
    rule: (concatS('Super', 'man') === 'Superman')
  },
  {
    label: "concatS should return a value of type String if passed two strings",
    rule: (typeof concatS('Super', 'man') === 'string')
  }
])


Keep up the good work Ady. I will be using dotLog.

:)

AND THERE IS MORE! How about dotLog described by dotLog


dotLog.describe("dotLog", [
  {
    label: "dotLog is an Object",
    rule: (typeof dotLog === 'object')
  },
  {
    label: "dotLog has two properties",
    rule: (Object.keys(dotLog).length === 2)
  },
  {
    label: "dotLog.describe is a function",
    rule: (typeof dotLog.describe === 'function')
  },

  // {pending tests here to get it working in node.js console},
  // { and so on, and so on. I think you get the idea! }
])

Of course, I'm just kidding. You really should'nt have something that is'nt tested, testing itself! But it was just a moment of madness.

All the best :-)

You are so simply the best mate!!! And that’s very motivating that you could already find use for it.
You just became the official first adopter lol.
Thanks and let’s keep at it.
Cheers

You keep at it mate!

Remember, take your time, don't rush it. Anything worth doing is worth doing well.

:-)

Catch you later.

PS.

Incidentally, when I first took a quick look at the dotLog code I did'nt have much time, but I noticed within the .describe method you were mapping over the testSet array and also that testSet contained objects with two properties label and rule; but still the "penny had not dropped" (ie. I had not got that aha moment). When I looked again at dotLog, some hours later, I then found your .png file(console-test-call.png) and instantly new what was going on.

Now, I'm just telling you this so that you know how important the example you provided in console-test-call.png was to understanding your code.

I think that, for me atleast, was something worth remembering.

Hey Ady,

Just thought I'd give you a heads up on a new log function I propose for dotLog. It basically addresses the issue of logging to nodejs. ie. after the environment that dotLog is running in has been detected, it selects the correct syntax for console.log in node or browser.

I've put it up on repl.it just for a quick preview.

repl.it/@johnboy5358/dotLog

cheers :-)

Great I think we have similar ideas on that. I looked at a package called colors yesterday for the node side of things. The next step was to find a way to detect the environment and to do the appropriate output.
I’m glad you beat me to it 😀

Yes, I saw the colors package, but thought it might be a case of a "sledgehammer to crack a nut"; so decided not to. However, Ady, dotLog is your project and of course you should always have the final say since only you know which way you want to take it.

:-)

No no it's not mine it's open source lol :) The best approach should prevail. I like the simplicity of what you have put together. When I did my initial research colors was the first option that came up. The idea will be to have something as lean as possible.
Please feel free to suggest alternatives and may the one that makes most sense win. It will be of great benefit if you feel entirely enabled to make or suggest whatever you see fit. Cheers :)

code of conduct - report abuse