Let's break it down. We'll assume for the sake of simplicity that Algorithm::BinPack does what it says and that we don't need to test that. So the things you need to test are:

1. Does the mkdir create the directory you want for the output?
2. Does the while loop find all the files in the directory you're backing up?
3. Does the list of files per bin look right?

You can't test any of those as the code is currently organized because the logic's all in line. If you wanted to be able to test this (and you should want to; you're depending on it to back up your data!), you'll need to reorganize it so it's testable.

It's not necessary to go all the way to a separate package; you can get away with wrapping the functions in subs and then modifying your main-line code to call them. You can then add a way to run a test vs. doing a backup via Getopt::Long or an environment variable. (Personally I'd spend the time to create the package simply because I could leverage Perl's build-and-test infrastructures.)

On a cursory scan, I think this

$dir or die "Can't mkdir $dir: $!";
[download]

doesn't do what you think it does. If you qx() the string in $dir then it will be executed, but just referencing it like this, Perl will only check it to see if it's "true" (i.e., not null in this case), and will not execute it!

The while loop may work, but honestly, you need to test it to be sure that it does.

A couple other notes: what happens if one of your files is bigger than a DVD? (Right now you'll attempt to mv it and fail.)

If the subroutine wrapping seems like too much work, then you should at least create some sample directories to be backed up, figure out by inspection what should happen, and then run the script to see if it does. If you change the size of a DVD to (say) 500 bytes, you can create a few files of a couple hundred bytes each and try it out.

EDIT: typos.