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
  • 969

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,463
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,798
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.

iteratingself
  • 8,703
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
  • 596
  • 5
  • 14
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,115
  • 17
  • 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,096
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,241
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