Following from comments in question:
Trying to reduce the number of tables is going to obfuscate their intended purposes. When you are trying to design a relational database of object, ask yourself two questions about each relationship. Is A a B? Does A have a B?
You've got a series of has-a relationships. (Specifically, has-many) Template has units. Template has testplans. Testplan has units (but, as you'll see, different units)
For each has-many relationships, you'll add a foreign key column to the property table, e.g., the unit would have a template_id.
parent_id (FK) -- references same table?
With a schema like this, there's no confusion as to what tables and what columns relate to what other objects. This makes querying very easy as well.
FROM Template a
JOIN TemplateUnit b
ON a.id = b.template_id
JOIN Testplan c
ON a.id = c.template_id
JOIN TestplanUnit d
ON c.id = d.testplan_id
Now you know that all b columns are template units and all d columns are testplan units. Easy peasy.