1. Start small, then extend.
2. Change one thing at a time.
3. Add logging and error handling early.
4. All new lines must be executed at least once.
5. Test the parts before the whole.
6. Fix the known errors, then see what’s left.
Taken from here: https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...
1. If at all possible start from something existing. It is entirely possible by the time you are done nothing remains of the existing. That's fine. To me, it's easier to tweak existing code than fill in an empty editor window. To some, an empty editor window is all opportunity, to me, it's analysis paralysis.
2. Always be ready to throw everything away. You perhaps will save a few choice lines but be ready for your first, sometimes even the second solution to suck badly. This is fine. Putting in more time to have an easier to maintain solution is always useful.
3. To continue from there, easier to maintain code is king. Unless you are writing something extremely time critical do not try to be clever. A little slower is okay (and yes, I am in the performance consultancy business) if it significantly decreases the maintenance burden. Clever hacks belong to toy projects and blog posts. The next person who maintains it will be stupid to the code -- even if it's yourself. That clever hack is now a nightmare to untangle. In short: always code under the assumption that you will need to understand this when the emergency phone kicks you out of bed after two hours of sleep in the middle of the night. The CTO of Cloudflare was woken to the news of Cloudbleed at 1:26am.
What if you write a function in Go that's littered with the usual
if err != nil {
return err
}
1. Return something meaningful, not the bare error you received above.
2. If you do nothing but decorate the error, ignore coverage. Having decorated the error helps debug the full system when the error occurs.
3. If your error handling is more complex (remove temporary files, close handler, etc.), you might want to factor the cleanup into its own function and test it there.
Finally, your code is not really "littered." If you had exceptions, there would be no trace of the possible errors that might occur on the production system. Your coverage will be higher, but when the software will blow up in production, it will not matter then least.
Creating tests for some of these cases would involve mocking things out, and then you have to make assumptions that may not hold anyway. That's why I like to see it execute in the real environment at least once.
Yes, a lot of things like that are possible. I remember in one client-server project I worked on, we unplugged the network cable from one PC (while the program was communicating between client and server), to see if we got the correct error message that we had written for that case. And did other stuff like that.
This was done in a project I handled, for the World Bank. I had a team of 9 motivated though young developers (first project for most of them). Near the end, before we sent the software to the client, a colleague was assigned to test the software - testing by a member external to the team, a slightly senior guy, ex-CITIL (a Citi IT subsidiary which had more mature software processes than we did then), though of course we did test the software ourselves a lot, first. I remember what happened:
We prepared the machines and software for the test. Called him over.
He said: I am going to sit down and destroy your software.
We said: Go ahead, please try.
And he tried to. But could not. He only found a few minor cosmetic defects.
Getting up after a few hours of rigorous testing, he said something like - I am happy with your work.