16

My workflow has always been to write one logical step and then run the program and inspect the output. This process have served me incredibly well for assignments in university. However, as I do more development, there are often times when simply compiling and running your code takes 1 to 2 minutes. Examples include uploading a program to a microcontroller, requiring interaction with an external server, and unable to implement automation due to authentication, software architecture, or complexity.

These types of tasks are very unsuitable to how I usually program, and I'm having difficulties coding effectively. I usually make a lot of syntax errors and logic errors, most of which I easily catch by testing. However, with such a long wait time, this method is too time consuming.

Anne Nonimus
  • 979
  • 1
  • 9
  • 10

8 Answers8

25

First off, any sort of interactive debugging is great. You want that in your toolkit, because if not yet, then someday you will really benefit from having it. (Details vary by language, platform, and IDE.)

requiring interaction with an external server, and unable to implement automation due to authentication, software architecture, or complexity.

I'd look into some frameworks for using mock objects. These allow you to surround the component being tested with a fake ecosystem of other components, so that your tests are more specifically-targeted and you can avoid testing everything as a whole unit as much.

In addition, the mock objects themselves can be programmed in with assertions, so you can check that the component-being-tested really did make a certain call.

Darien
  • 3,453
  • 2
  • 19
  • 18
12

I would work hard to reduce the test time. I had worked in a couple of companies developing embedded code, and testing was painful, requiring trips to the server room and manual FTPs and reboots and multiple commands to the test hardware. Then I joined a really good group, where I could simply type 'make test' at my desk and get results back in under a minute. In that one minute:

  • My code was built into a new kernel image for embedded hardware.
  • The DHCP server was updated to point to the new kernel.
  • The test board was rebooted.
  • The test board retrieved the kernel from my workstation via an NFS mount.
  • The test board rebooted to the new kernel.
  • The unit tests were run.
  • The unit test output was delivered back to my workstation.

It took some time to get all this working, but the effort to automate all these steps was recouped a hundredfold as the development staff grew.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • 2
    +1. There is no problem that cannot be solved with a sufficient amount of shell script. – Tom Anderson Jun 09 '11 at 14:19
  • 1
    I won't stay in teams that don't care about improving velocity. – kevin cline Jun 09 '11 at 15:23
  • @Tom Except too many layers of abst--er, shell scripts ;) – Darien Jun 09 '11 at 17:37
  • Nah, you just write a shell script which wraps the other shell script. Then there's just that one shell script. TRUST ME. – Tom Anderson Jun 10 '11 at 08:55
  • 3
    +1: Improving the velocity of edit -> compile -> load -> run -> debug -> edit is the single best thing you can do to speed code production. When I worked at Tymshare we had a guy who claimed (correctly) that his code ran correctly on the first try 87% of the time. I, on the other hand, coded like I was overdosed on caffeine monkey at 1am (which I was). I made a ton of typo errors, etc., but I didn't worry about them because I knew the compiler would catch them. At the end of the day I was probably 3 to 5 *times* more productive than he was. – Peter Rowell Jun 10 '11 at 19:33
  • @Peter - Errors like *"I was overdosed on caffeine monkey"*? It's important to remember that prose isn't compiled when you have to make a switch (for example, when writing comments). – Kevin Vermeer Jul 20 '11 at 18:26
  • @Kevin Vermeer: Hey! You are clearly *not* my wife because a) you're first name is Kevin and that just could never work for me, and b) I rather doubt you are a retired Senior Editor from Addison-Wesley. If you *were* my wife you would have pointed out that the word 'an' was missing from in front of 'overdosed', and also that it should have been 'overdosed-on-caffeine monkey'. She would think about chiding me for not putting that last period inside the quote mark, but she's found out I'll just say, "I'm a programmer.", and that that syntax rule is silly. :-) – Peter Rowell Jul 20 '11 at 20:43
8

Automated tests are not replacement for review and understanding.

It may be that you are using testing as a crutch. If you are doing this you will impede your learning. I am not advocating you don't test. Instead I would recommend you that before you run your test review what you wrote. Understand what you wrote, make sure it makes sense and make sure the syntax looks correct.

dietbuddha
  • 8,677
  • 24
  • 36
5

You already gave the answer: I usually make a lot of syntax errors and logic errors

So working hard on improving that, you should be able to reduce the time on testing. The syntax errors should be the very first you should reduce. Never had a programming test with a paper and a pencil in your study?

I had the same thing when I switched from PHP to Java. I had to learn to debug instead of just printing some variables and press F5 in the browser...

WarrenFaith
  • 594
  • 5
  • 14
  • 2
    We all make stupid mistakes from time to time, they only occur less with time and experience. – maple_shaft Jun 08 '11 at 18:41
  • @maple_shaft thats true, but when he says `make a lot of` it sounds like he should invest his energy to improve it – WarrenFaith Jun 08 '11 at 18:57
  • 3
    I did a fair amount of coding on paper and on whiteboards. The problem is the same: the code looks right on the first inspection, but after running it, you notice your mistakes. – Anne Nonimus Jun 08 '11 at 19:10
  • noting mistakes in code and writing code with wrong syntax is a big difference. The first one can happen to everybody, the second one suggest beginner level. I do not know your background, but even as a beginner you should minimize syntax issues. Whats your IDE and language? It should support syntax checks. – WarrenFaith Jun 08 '11 at 19:21
  • @Anne Nonimus: Do you mean logical errors? Syntax errors should be picked up by your IDE (ideally - if you are working with code that's dynamically generated then those syntax errors will not get picked up at compile time). – FrustratedWithFormsDesigner Jun 08 '11 at 19:24
  • @maple: Eh. Syntax errors are sloppy for the most part. When you're kernel hacking, or compiling anything else that takes more than an hour, you need to check and check and check. – Satanicpuppy Jun 08 '11 at 21:16
4

You need a good Unit or Functional test platform that can automatically run tests for you, preferably in the background. This will require the use of Mocks as noted above and depending on the language you are using some sort of dependency injection.

By making your objects as independent as possible and then using injection methods to add outside constraints it is not hard to create a test platform for your code.

Bill Leeper
  • 4,113
  • 15
  • 20
2

The real fun comes when you simply can't test your code except by using it in anger. This happens quite a lot with trading systems, as the exchange simulators available are often either poor, non-existent, or don't even comply with what the suppliers of the exchange software say it does. This is part of life's rich tapestry I'm afraid. My approach is to make sure at least my side of the transaction is well-written and well-documented, so it can easily be changed quickly.

Neil Butterworth
  • 4,056
  • 3
  • 23
  • 28
  • 3
    You "exchange" and "trading" software engineers are a unique breed. My friend had a series of mental breakdowns working for one such company. I never hear good things come out of that niche of the software industry. – maple_shaft Jun 08 '11 at 20:14
  • @maple Well, I don't do it any more myself. But unique? Nah - anyone can write crappy code, and most trading code is deeply, deeply crappy. However, like it or not it, is the basis for our society. – Neil Butterworth Jun 08 '11 at 20:23
  • Yeah, I heard the same thing about telecom code and how many millions of lines were in switch control software. Then I joined a Telecom company and realized that if they had employed some programmers thousands of lines would have been sufficient. – kevin cline Jun 09 '11 at 05:06
2

Unit Testing; Mock applications/simulators.

This will take time, granted, and you may need to collect and massage sample data to create appropriate mock-ups, but it will pay off in the end: You will save yourself all the time and trouble you encounter when trying to test against external systems.

Used correctly, these tools will ensure that before you go anywhere near external systems, you're 99.9% sure that if your code fails, it's something in the external system/change of environment that caused it, not a bug in your own code.

I worked professionally for quite a while they way you did in school, and in many cases it was very effective. Eventually I worked under some people who forced me to abandon that methodology and use unit testing and mock-ups instead.

Now, I do not start any project without first thinking through the implementation of the testing phases - unit testing, mock-ups, simulators, sample data, etc.

Vector
  • 3,180
  • 3
  • 22
  • 25
1

I usually make a lot of syntax errors and logic errors

Maybe using a Linter can help you a bit here.

I was in similar situation with my previous employer. Our code base was really huge and to make any changes I had to code, compile then replace .class files in a dev-server then restart the dev-sever with restart script. And to my dismay, it will take about half hour to get dev-server up again.

Later I found out that Remote debugging the dev-server was also possible.

So here is what I did to optimise my process

  • First initial round of remote debugging, this allowed me see the exact code flow and exact values/states of variables.

  • Planing how and what changes I will make.

  • Making Changes and then comparing the diffs

  • Caching mistakes by using linter or by compiling.

  • Giving the hot fix by replacing the .class files and restarting.

Sometimes I would also include a hell lot of log statements to again check the code flow and to check check for values/states. This did helped me a lot.

Also using a IDE with good auto-complication can greatly help in reducing typos.

Hope this helps.

Alaf Azam
  • 11
  • 2