In a text editor environment, I find that I put a console.log() if I'm >coding in JavaScript, or puts in Ruby after every line as I'm checking the >values of my code and seeing if it is operating the way I intended.
In this case it would be better served to write tests and validate code is working the way you intended via assertions.
Writing tests only really check that the entire function is working as intended. They're nice to have since it can show that you know how to test and that your code works.
The problem is:
Writing tests take time you might not have
They don't help you narrow down an issue.
You need a way of debugging specific lines are wrong so you know what you need to fix -- The simplest (and best) method is console.log as Sofia suggests.
Writing tests will save time in the long run. Writing them before you write the implementation is preferred.
They don't help you narrow down an issue.
If your code is structured properly (aka small functions/classes responsible for singular things) unit tests will tell you at exactly which point your test is failing.
While I agree in a general sense, this article is about coding during an interview -- there is no "long-run" if you only get an hour to solve the problem. If you're spending a significant amount of time writing tests, you're not spending that time answering the question.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In this case it would be better served to write tests and validate code is working the way you intended via assertions.
Yes and no.
Writing tests only really check that the entire function is working as intended. They're nice to have since it can show that you know how to test and that your code works.
The problem is:
You need a way of debugging specific lines are wrong so you know what you need to fix -- The simplest (and best) method is
console.logas Sofia suggests.Writing tests will save time in the long run. Writing them before you write the implementation is preferred.
If your code is structured properly (aka small functions/classes responsible for singular things) unit tests will tell you at exactly which point your test is failing.
While I agree in a general sense, this article is about coding during an interview -- there is no "long-run" if you only get an hour to solve the problem. If you're spending a significant amount of time writing tests, you're not spending that time answering the question.