BigDecimal wrapper that ignores zero operands
There are big problems with your approach.

Cloning BigDecimal with .doubleValue() is broken

Cloning a BigDecimal bd using new BigDecimal(bd.doubleValue()) doesn't work in most practical cases.
For example, try this code:


BigDecimal bd = BigDecimal.valueOf(0.02d);
BigDecimal clone = new BigDecimal(bd.doubleValue());
System.out.println(bd);
System.out.println(clone);
System.out.println(bd.equals(clone));



On my computer the above code prints:


0.02
0.0200000000000000004163336342344337026588618755340576171875
false



The equality test fails for as simple values as 2d. It passes for a simple 2, but that's not very reassuring.

As such, your current implementation of cloning doubles is effectively broken, for example this test case fails:

@Test
public void multiply_2d_with_3d() {
    BigDecimalWrapper v = new BigDecimalWrapper(2d).multiply(BigDecimal.valueOf(3d);
    assertThat(v).isEqualTo(new BigDecimal(2d).multiply(BigDecimal.valueOf(3d));
}


You can fix it by replacing .doubleValue() with .toString(),
the unit test will pass.

Cloning BigDecimal is a strange thing to do

BigDecimal instances are immutable, so you can safely pass around copies.
Creating new instances is completely unnecessary.
Your current approach forces you to clone.
Since cloning is non-sense, this indicates a code smell,
and that a better solution is probably available.

Composition over inheritance

A better approach would be to avoid the strange cloning, by making the decorated object a final field in your wrapper class. Add a constructor that takes a BigDecimal, and call that one instead of super. 

By the way, putting the decorated object into a field of the decorator class is the common technique when implementing this pattern (composition instead of inheritance). It makes it possible to nest multiple decorators in arbitrary order. Inheritance is a very tight coupling, composition gives you much more flexibility.

For example something like this:

class BigDecimalWrapper {

    private final BigDecimal bigDecimal;

    public BigDecimalWrapper(double num) {
        bigDecimal = new BigDecimal(num);
    }

    public BigDecimalWrapper(BigDecimal bigDecimal) {
        this.bigDecimal = bigDecimal;
    }

    public BigDecimalWrapper multiply(BigDecimal augend) {
        if (augend.compareTo(BigDecimal.ZERO) != 0) {
            return new BigDecimalWrapper(bigDecimal.multiply(augend));
        } else {
            return this;
        }
    }

    public BigDecimal bigDecimalValue() {
        return bigDecimal;
    }
}


Since the class no longer extends BigDecimal,
I added a bigDecimalValue() method to get access to the wrapped object.
The unit tests can be modified to work with this, and they pass:

@Test
public void shouldMultiply() {
    BigDecimalWrapper v = new BigDecimalWrapper(10).multiply(BigDecimal.ZERO);
    assertThat(v.bigDecimalValue()).isEqualTo(new BigDecimal(10));
}

@Test
public void multiply_2d_with_3d() {
    BigDecimalWrapper v = new BigDecimalWrapper(2d).multiply(BigDecimal.valueOf(3d);
    assertThat(v.bigDecimalValue()).isEqualTo(new BigDecimal(2d).multiply(BigDecimal.valueOf(3d));
}


You might not like that fact the BigDecimalWrapper is no longer a BigDecimal.
But maybe that's a good thing.
With your implementation,
if somebody ever tries to use a BigDecimalWrapper instance as a BigDecimal,
he might be surprised that multiplication with zero doesn't work as expected from a BigDecimal.
For this reason I think it's a good thing for BigDecimalWrapper to not pretend to be a BigDecimal.

If, however, you really want BigDecimalWrapper to be a BigDecimal,
then the most sensible solution is to keep your original implementation,
with doubleValue() replaced with toString().