While you are in TestDoubleArraySeq.java, add a really simple test case
so that you can get a green check for something when you write the code
for the constructor. I added this:
   /**
    * try to break the constructor
    */
   @Test
   public void initial( ) {
      DoubleArraySeq s = new DoubleArraySeq( );
      assertTrue("Initially no items", s.size() == 0);
      assertTrue("Capacity should be default of 10", 
            s.getCapacity( ) == 10);
   }

What else could we check there? We could create another test to detect the
bug of ignoring the size the user asks for as an initial capacity. That
would look like:
   /**
    * try to break the constructor
    */
   @Test
   public void initialCapacity( ) {
      final int capacity = 25;
      DoubleArraySeq s = new DoubleArraySeq(capacity);
      assertTrue("Initially no items", s.size() == 0);
      assertTrue("Capacity should be user requested size",
         s.getCapacity( ) == capacity);
   }

The pattern here is to have a comment and @Test followed by a public method
with a unique name. In JUnit 4, that name doens't have to start with test.
Then set up a sequence, do things to it, and use the methods of the class 
to inspect its state. It's better to have many small tests than big ones.
many of the ones we give you are really too big.

Suppose you wanted to check whether the exception is thrown for a negative
capacity. That test is a little different. It states up front which exception
should be thrown (note the .class at end of exception name):
   /*
    * Looks for bug in trying to initialize with negative capacity
    */
   @Test(expected=IllegalArgumentException.class)
   public void negativeCapacity( ) {
      DoubleArraySeq s = new DoubleArraySeq(-1);
      
      assertTrue("Initially no items but object should not be created",
                   s.size() == 0);
      assertTrue("Should have thrown exception in constructor", false);
   }

We will be testing your DoubleArraySeq class with our own JUnit tests (mostly
what we gave you) and not using your tests. So feel free to modify your tests.
Or you could have your own test file that grows with what you've implemented.
Make a copy of the existing test file, rename it (file and class name), and
remove (commemt out) the parts you haven't implemented yet.