It seems like such a foreign concept to some...
What do you guys think?
It seems like such a foreign concept to some...
What do you guys think?
Your question is kind of vague. Which programmers? Are you referring to the students who make up a bulk of the questions posted here? The teachers who guide students in their learning? Teams whose projects you've worked on or used? Professionals you've worked with in the field? On what are you basing your opinion?
While I'm not sure exactly where you're coming from, I am inclined to understand your general point. But from my observations, it's not a problem exclusive to the programming community - any field that relies on the application of science should ensure certain criteria are met during development. But in reality, this is not always the case.
Perhaps because, for many people, after sufficient knowledge is acquired, the resulting day-to-day work becomes merely a "job" over time and no longer a burning passion. We are just humans, and our chaotic minds and ever-shifting whims can easily take our attention away from the task at hand, when it is no longer engaging to our mind. There's also the fact that some people just never have the desire to go very far in their field.
Like everything in this life, though, it's a double-edged sword. On one hand, it sucks when people do not do their jobs properly. On the other, if you excel, it gives you a chance to rise and succeed.
I'm not sure if you were expecting such a philosophical response, but that's what I came up with after reading your question.
I'm going to respond to this series of questions with, "yes", by which I mean, yes to all your questions.Your question is kind of vague. Which programmers? Are you referring to the students who make up a bulk of the questions posted here? The teachers who guide students in their learning? Teams whose projects you've worked on or used? Professionals you've worked with in the field?
The students here, no doubt. It doesn't seem to me like testing makes up any non-trivial part of the education but that's kind of okay though. It's mostly just undergrads and let's be honest, undergrads just don't know anything. And yes, I do say that with myself included. My undergrad self was an idiot. It's amazing anything stuck at all. So I cut students the most slack.
By that logic, I can't really blame the teachers then. Okay, I can. I know this is not an absolute and something like unit testing can only go so far but for most early education, it'd help students the most to teach them how to write small and compose-able functions that they can pull out and test in isolation. "Write a function that returns a free-standing node of a linked list containing a copy of the data passed into it. Write tests that prove correctness and error handling." Something like that. Code is far less complex when you have "physical" proof that your functions are doing what they're supposed to and not doing what they're not supposed to.
As for teams, that's what's made me a test-writing lunatic. I've found a really good lead programmer. Their skills of abstraction are pretty great and it's influenced me in a large way. My latest revelation is testing frameworks. I've seen first-hand why testing frameworks are far and above the most amazing thing for software projects. You have like 1/10th the fear you do when you refactor or add new code to the base. It's super nice just running your code through a test suite so you can tell yourself, "Sweet, I didn't break anything!" That's fundamentally the goal, don't break your code. Having a rich and in-depth testing framework does nothing but good things.
And now for your last question, this is why I made this topic in the first place. Basically, I wound up getting into an online chat war because some person didn't see the value of testing. They even went so far as to say that, "I write code that can't be tested" to which I immediately scoffed, "Maybe you're writing your code wrong...". I'm, of course, paraphrasing but it bothered me nevertheless.
The code in question was some low-level stuff in C/C++ where they were, I think, live-injecting instructions to a DLL or the stack or something, I can't remember but it was something like that. Basically, it was amazingly easy to hash out a testing suite for the code even though I barely understood the problem. Write a function that generates a set of instructions. Test that. Write a function that injects a set of instructions. Test that. Ridiculous.
The Linux kernel does not have a test suite.And now for your last question, this is why I made this topic in the first place. Basically, I wound up getting into an online chat war because some person didn't see the value of testing. They even went so far as to say that, "I write code that can't be tested" to which I immediately scoffed, "Maybe you're writing your code wrong...". I'm, of course, paraphrasing but it bothered me nevertheless.
The code in question was some low-level stuff in C/C++ where they were, I think, live-injecting instructions to a DLL or the stack or something, I can't remember but it was something like that. Basically, it was amazingly easy to hash out a testing suite for the code even though I barely understood the problem. Write a function that generates a set of instructions. Test that. Write a function that injects a set of instructions. Test that. Ridiculous.
So, a patch that looks okay, builds and results in a bootable kernel is accepted.
That seems terrible, but I doubt there is a better solution.
It is indeed very difficult to test code which, for example, depends on the availability of specific hardware.
Another example would be UI code, for which some forms of testing are possible, but not really anything comprehensive.
Last edited by manasij7479; 02-27-2016 at 12:04 AM.
Dude, Linux is absolutely tested before each and every release. It's not '98 anymore.Originally Posted by manasij7479
Did not know about this, thanks.
Phew. I was gonna say...
Anyway, I'm sure I came off as a jerk in that situation. I was triggered though. They started badmouthing Node.js because they messed up their callback's function signature/method of invocation. This is true of almost all languages but they literally only do what you tell them to do. I couldn't imagine not taking the blame in that case. It's not JavaScript's fault that someone can't spell or remember how to call a function... Granted, it is definitely a point in the favor of compiled languages that they would've caught it for you.
However, that makes it even more important for code that is interpreted at run time to be covered by automated tests and to be checked with static analysis tools.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Yes! Exactly.
Though I must admit that the compiler is an amazingly powerful tool. But compilers do not catch everything, unfortunately. I definitely have lots of runtime errors too.
Is there still ........ty/buggy software out there? The answer to that question is yes, so the answer to your question is no, testing is not emphasized enough.
Unit testing shouldn't be concerned only with errors. A bug is also a failure of the program to perform according to the programmer desire. Unit testing is a particularly important tool in catching a failure to meet software specifications. In the case of TDD techniques, they can even help define software specifications.
As for the person you were talking to, unit testing isn't new. It's older than dirt, as old as software development. But only recently it did get mainstream attention. The problem isn't with him, or students, or teachers, or developers in general. The lack of comprehension of the value of unit testing is mostly the fault of its advocates who like to push the concept as in those afternoon infomercials that are guaranteed to save your life, make you happy and live healthier. The popularist and dishonest push towards Agile development, which is guaranteed to not be an ideal solution in every case, has muddled the waters and created the confusion in many people's heads that the *very* old practice of unit testing cannot be dissociated from such practices as Agile development or even TDD. Which is not the case.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Oh my God... I am the problem...
So... What's a good way to convey to someone who doesn't see the value of testing that there is value in testing? The lesson was only really instilled in me because it was basically forced on me.
Seriously, you are not. You were advocating a time-honored best practice in computer programming and with equivalent counterparts in every engineering field.
Again, it is important to distinguish unit tests from test-driven development (TDD) practices like Agile, Extreme or Scrum development. Unit tests form the backbone of TDD, but they don't need to be used in that context. TDD is a younger concept than unit tests and, depending on the development environment, unit tests can be used outside any sort of TDD technique. Most often that is exactly how they are used (outside of TDD).
I would probably tell them, outside of TDD:
- Testing increases the time spent writing code and decreases the time spent debugging. Since the latter accounts for the the most time spent while developing, there is a net gain once a programmer masters the concepts of unit testing.
- Unit tests are a standard industry practice. Might as well get used to them if they want to work in this field.
- Unit tests do not necessarily need to achieve 100% code coverage. Not even 50%. Ideally they should, but common sense will dictate what parts of the code should be covered. Common sense is acquired with practice.
- Unit tests are the best known safety mechanism for code refactoring, with the potential to greatly reduce application maintenance costs.
- Unit tests represent a code framework that facilitate code documentation, help discipline the programmer by enforcing a divide and conquer strategy to programming, and even greatly increase the effectiveness of code source control by more easily referencing regressions, merges and forks.
- Unit tests are of very little use in small code footprint projects, without many logical parts and with a focused behavior, that can be generally understood in its entirety by a single person in an afternoon.
- With the above in mind, do not use unit tests if you don't want to. Use them if you do.
Last edited by Mario F.; 03-01-2016 at 10:31 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
How long is a piece of string?
You know what though? No. Programmers don't emphasize testing enough. I think as a general statement that's fairly safe.
EDIT: Oh... but as far as code coverage by the unit tests... hitting 100% should be the goal, really. If you can't figure out how to get code to execute with a unit test, rework the code until you can. I find this forces the architecture in good directions.
Last edited by brewbuck; 03-07-2016 at 11:59 PM.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
