Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I want to write an application that can be used to burn CDs (music). I know I should test it with real CDs anyway, but I don't want to do this every time I make a small change. But I do want to know and test if the right data will be burnt, so you don't get corrupted CDs.

I am using a library which only exposes APIs to directly burn to a physical drive; it doesn't allow you to write to a disk image (which would be much easier to test).

How could I test this without wasting CDs and time for every change/few changes I make?

share|improve this question
Would it be possible to switch to a library that does allow you to write a disc image? –  FrustratedWithFormsDesigner Nov 4 '11 at 16:34

5 Answers 5

up vote 30 down vote accepted

The simple answer is often the best: re-writable CD's?

Also for saving time, write relatively small files. Only do larger files every so often.

share|improve this answer
I agree this is a simple and good answer, but if WTP wants to take testing to another level, mocking the API (see other answers to this question) will unlock a whole dimension of testing possibilities (as in, automated). –  louisgab Nov 4 '11 at 18:35
@louisgab I totally agree with you, when I wrote the answer I was only really addressing the point about wasting CDs. I fully expected another answer to come up with something better (and they have). If anything, I would recommend the mocking approach, and suggest my answer only when WTP actually wants to physically test the burning process. –  Kevin D Nov 5 '11 at 9:55

If you are on linux, you should be able to set up a "cd device" that is just a named pipe. Your api writes to the "device" and you hook the other end up to a program that lets you see what it does/convert it to a disk image. Lots of options there. See this article for info on named pipes.

Kevin's answer is far easier IMO.

share|improve this answer
I am actually on Mac OS X which is also a UNIX system. I'll give this a try. –  rightføld Nov 4 '11 at 15:41

What testing are you exactly talking about?

Reading "I don't want to do this every time I make a small change" in your question, I imagine that you are talking about unit testing.

But later, you add that you're using an API which is in charge of burning data to CDs. If this API is tested and documented correctly, you don't have to deal with actual process of burning the data to the CD, and you don't have to test it. In this case, you deal with integration testing, that you don't have to do "every time [you] make a small change".

share|improve this answer
But I do need to know if I am using the API correctly. –  rightføld Nov 4 '11 at 15:40
@WTP: see my edit. Also, a correctly written API would not allow you to create corrupted CDs by using it incorrectly. If it does this sort of things, you should probably search for another API first. An API is here to provide an abstraction and especially to avoid to deal with the ways to avoid corruption when saving data to a CD. –  MainMa Nov 4 '11 at 15:46
You do have a point there. The API is very well documented. –  rightføld Nov 4 '11 at 15:49

Write as many tests as you can that use a mock of the API of the library. This allows you to test your code in units. This shows that your code works within itself assuming that the library performs the way it is supposed to.

At some point, you will need to do integration testing that actually does use the library. But the point is that you already have a level of confidence with your own code before you get to the this point. Integration tests often take more time and resources, as you've seen. So thorough unit testing allows you to not rely completely on integration testing.

share|improve this answer


Since you want to test your software (not the API, nor the recorder), as Chris pointed, a mock of the API would be necessary.
For the integration testing, a reliable "ISO" recorder should allow you to automate the testing of the CD contents by analyzing the .iso file.
Actually burning a CD or DVD would not render conclusive results, since you wouldn't be able to determine whether the error cause is a defective CD, a defective recorder or a software bug, unless you want to perform quality statistics by recording multiple copies of the same disc (wich you apparently don't).
Good luck!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.