While I agree with Robert Harvey's statement, that test driven development is a useful approach, I often do get the impression that people think that with sufficiently many unit tests in place they are on the safe side and are allowed to stop thinking about useful tests. This, I think, is far from being true.
In my opinion creating reasonable tests is something between an art and good craftmansship, where knowing about existing tools and best practices together with thouroghly and correctly applying them is the craftmanship part. Good knowledge about common programming errors as an additional ingredient will also help to find useful tests. But you also have to understand the problem solved by the algorithm and need to get an idea of where an implementation is likely to fail. You will, at least partially, often be on your own here. I'd try to find at least one alternative algorithm and run them concurrently. Often you choose a specific one for performance -- in automated test you may use a slower one for croos checking. Whatever helps is somehting you can put into the best practices box.
Without spending too much time on it, for the problem you gave as an example I'd try to find an (automated) way to (randomly) create (many) sequences of varying length for which I can predict the result. Then feed them into the algorithm, and log the input in case it fails. In addition I'd do that for a fixed (not random) set of sequences as a protection against code changes which might break the code. I'd make sure there will be sequences with more than one solution and try to figure out whether sequences with overlapping solutions exist and if yes, try to create some of them, as well.
I'd like to add that for me, as a mathematician, an algorithm is either correct or wrong for at least one set of input data and it is something for which you can (often) give prove (the link is more or less randomly chosen) -- of course there is always the human factor....But even if you believe that, you cannot do that (give proof) for an implementation of a (sufficiently complex) algorithm, which is the thing which is actually under test.
Edit I think an example which is sufficiently obvious and elaborate at the same time might be useful. For this I'd like to draw your attention to Knuth's 'The art of computer programming' vol 2, where under the heading 'The classical algorithms' an algorithm is presented which shows how to divide an (arbitrary) positive integer by another positive integer. Knuth actually gives (a somewhat hard to understand) proof of why his algorithm is correct. A certain part of that proof shows that there is a straightforward way of performing a certain task in that algorithm and an exceptional case. The exceptional case (see step D3 in algorithm D if you really want to look it up) occurs extremely rarely and, actually, requires a more complex calculation.
Now while there is a quite obvious way to create unit tests for this algorithm (apply it to two integers and then perform the reverse operation to check whether you get to from where you started) it is absolutely not obvious how to make sure the exceptional case is tested. First you need to know about it (that is, you have to understand the hairy details of the proof of the algorithm), then you need to find data for which it will actually occur. Doing the whole chain (finding the algorithm, which is, in this case, done for you by the author, finding a proof for it, identifying the exceptional cases and making sure test data is found which test this as well) is not covered by any kind of best practice.