For these two examples, I would not describe the first steps as additional tests, they are asserting pre-conditions. These do add value in cases where this pre-condition for the test is not obvious to the reader. This could be the case where:
The way the tests are written means that it is not obvious to the reader that this pre-condition should hold true for the rest of the test to be valid. In this case, the pre-condition assertion helps to make the expected pre-conditions clearer to the reader. One scenario where this may happen is if your test data is being set up inside a setup method, as the separation between the data setup and the test declaration makes it harder for the reader to understand how the test works.
You are working with highly complex code (i.e. complex mathematical algorithms), where the complex nature means it can take a while to debug test failures and understand the cause of problems. In these cases, asserting your pre-conditions can greatly help with understanding the expected behavior of the test.
Of course, as well as improving readability, you also get the benefit that if the test fails due to a pre-condition then it will be easier to understand why the test failed. However, I would not start adding pre-conditions to tests just for this reason alone - if it is the case where you require pre-condition assertions just to help you understand the cause of test failures, it is probably because your tests are overly complex.
One thing I would add, if you are using assert statements in this way, I would simply add a comment above them to make it clear to the reader that you are using this assertion to check a pre-condition.
A final note - this answer has focused solely on unit tests. As you get into different types of testing (e.g. system tests exercising the whole software stack), where tests can be more fragile, then the argument for including pre-condition assertions in your tests becomes stronger.