

Common Mistakes Developers Make - kirtijthorat
http://thenextweb.com/entrepreneur/2013/12/24/9-common-mistakes-developers-make/

======
jrockway
Mistake number 1: not writing any tests.

I was watching some anime last night where the characters were trying to make
a computer game for some contest. They finished it, but it was too buggy to
play through to the end without crashing (or causing the computer to restart,
not sure how they managed that one), and they decided it would be impossible
to fix them all because the game takes five hours to play through all the way.

This is a common error, not one committed at random by a bunch of fictional
high school students. You should never need to use your program to check that
it doesn't crash after you've made changes. Your tests should cover this. If
you're loading up your web browser to see if your sort routine works, you're
wasting your time again and again. You have a computer that can be programmed
to do anything you want. Tell it to do what you would do if you were playing
your game or using your website. Then it can test your code thousands of times
a second, instead of once every five hours.

</rant>

This is also a good check to see if your code is reusable. If you can't reuse
parts in isolation to test your program, you're probably not going to be able
to reuse them in another program.

~~~
thirsteh
> I was watching some anime last night where the characters were trying to
> make a computer game for some contest. They finished it, but it was too
> buggy to play through to the end without crashing (or causing the computer
> to restart, not sure how they managed that one), and they decided it would
> be impossible to fix them all because the game takes five hours to play
> through all the way.

I don't disagree that tests (especially fuzz tests) are essential, but this is
a problem with dynamic and unsafe (unrestricted side-effects) languages, not
languages in general. You're very unlikely to write a program in a language
like Haskell, have the program compile, and then not work as expected.

~~~
jrockway
Not true at all. Consider this implementation of a function that checks if a
string is a palindrome:

    
    
       is_palindrome :: String -> Bool
       is_palindrome _ = True
    

You still have to test it.

~~~
thirsteh
My statement that you're unlikely to experience problems if you write
something in a language with so many compile-time checks isn't "true at all"?
Really? And if you really want to argue about silly examples, we can talk
about Agda instead, a language in which even your contrived example wouldn't
need any unit tests.

I never said that you didn't need tests at all, or that you couldn't
deliberately write programs that didn't work. I'm just of the opinion that the
heightened focus on unit tests is a symptom of a language that doesn't perform
such checks for you automatically.

I also very strongly disagree with your insinuation that you _need_ unit
tests. Fuzz tests can be much more powerful.

~~~
jrockway
I've written plenty of production software in statically-typed languages,
including Haskell. I write about as many tests for them as I do in other
languages.

Having also written a lot of Python, I don't find my software dying
unexpectedly from AttributeErrors. Instead, it merely produces the wrong
answer because the wrong code was in the method.

The advantage the compiler brings is the ability to refactor. With tests, you
don't know if you've gotten everything. But if you change a method signature
in, say, Java; you'll know immediately when you run the compiler. But it
doesn't mean your program will produce the right answer, it only means that
you're calling the function with the right number of arguments of the right
types.

~~~
thirsteh
You're disagreeing very passionately with points I never made. I literally
said "I don't disagree that tests are essential." I followed that up with the
statement that programs written in languages with compilers that perform a lot
of checks at compile time tend to work as expected, to which you responded
with "not true at all," and gave an extremely contrived example of something
that "needs to be tested."

------
adamnemecek
This article is an equivalent of a Cosmo article for developers.

~~~
thirsteh
At least it's not suggesting you poke your pair programming partner with a
fork to increase... productivity.

~~~
jrockway
You should have called it "reproductivity".

