Yep, that's quite likely and not necessarily a bad thing. Development
done correctly should only be a small portion of the overall project
time, and unit testing should be at least as long as development.
Spending three times as long writing the tests as the code ensures you
don't spend three or four times as long debugging problems in the code...

I've seen this a lot in classes I taught. A portion of the assignment goes
towards testing the application. Some students will write a 50 line
application and hand in, literally, 30 pages of test output.

You can narrow the testing down a little by thinking about how things can
be grouped. If the start of a method begins with an:

    if (case 1 is true) {
        // something
    } else if (case 2 is true) {
        // something else
    } else // case 3 is true) {
        // whatever is left
    }

I'm going to need at least 3 tests in jUnit.

If you have been programming for a while you noticed that at first you'd
right out 10 different if/elseif/else statement. As you refine the program
you realize that the solution for case 1, 3 and 7 is the same so you
combine them. This forms a compound boolean statement. There might be
multiple ways into the statement. Some will say you need 3 test cases for
the 1 boolean statement. The logic is that if someone messes up part of
the statement you might catch it. Others say that you only need 1 test
case because all 3 will exercise the same body; i.e. they are equivalent
test cases so you only need to pick one. Having 3 test cases for the 1
statement is safer. Is your boss willing to invest the time to code and
maintain them all?

As to what if test2 requires test1 to pass? I like to set up my tests is
the setup() function provides everything necessary for the test to
proceed. Therefore, the setup() for test2 is to ensure that the output for
test1 exists.

Another option is to map the dependencies and have test2 check if test1
failed. If test1 fails, don't even bother running test2. Or have an assert
at the beginning of test2 that checks for the success of test1 and outputs
good information in the log, i.e. "test2: failed. Relied on test1, which
failed."

I like to do the latter. That way if 3047 tests rely directly or
indirectly on test1 and test1 fails. The other 3047 tests are unknown.
Unknown is not a failure but it is a potential failure; could impact
schedule.

Finally, the de/compressing random data is a potentially good test. You
want to test that your code does what it is supposed to do but you also
want to test that your code does not do what it is not supposed to do. For
example, if you give it bad data it should die gracefully. It should not
format the hard drive, corrupt data or reboot your computer. It should
recover nicely.

   One strategy is to write tests until you don't feel like you're writing
useful tests anymore.

   Another strategy is to imagine yourself as being a "lead programmer" to
has to delegate work to "junior programmers". You assume that the junior
programmer has a vague idea of what the method (s)he has to code is supposed
to do, but doesn't know the details (e.g. what should happen at the
boundaries, like you mentioned above). Write enough tests so that the junior
programmer can be relatively confident that his/her code works, without
coming back to you to ask for clarifications.

   Also, while coding, if you notice a bug, it's usually a good idea to
write a test which will detect that specific bug so that it doesn't slip by
again.

   It might also be worth considering both "black box testing" and "glass
box testing". In the former (black box), you don't assume anything about the
implementation. You write tests that make sure the method does what it's
supposed to do, and that's it. In "glass box testing", you know what the
algorithm is that implementing the feature you're testing, so you'll write
tests which will ensure every line of code gets executed at least once (e.g.
make sure that both the "true" and "false" paths of every if statement are
taken).

   Usually you'll want to have a good mix of black box and glass box
testing.

   It's not unusual in test-driven development for one to spend more time
writing tests than writing code.

   Some people feel tests should be fast or else you won't want to actually
run the test. If you agree with this philosophy (I don't), then you probably
want to avoid the 2GB test file as that'll probably be a long test.

   Some people have configured their IDEs to automatically run unit tests
immediately after a compilation, so that the failed tests actually show up
in the error logs (e.g. as compilation errors or warnings).

   - Oliver