I know TDD has been discussed to death. However, I disagree completely with TDD encouraging creativity and material exploration. In my opinion, small, iterative increments are much more useful. Creating a test puts a tight box around how you assume (without any experimentation) an interface should work. As opposed to a tiny iteration to learn about how it could work. Then writing a test after for that tiny bit. Finally, moving on and refactoring with the test in hand.
Writing the test is the experiment, in your example. You're playing with how it is going to be used and interacted without worrying about the details/implementation. You'll take care of that later.
I don't see how you can experiment with functionality by writing tests at all. Tests are basically just pseudocode. It's writing the requirement/interface before figuring out what is possible.
For example. I was recently trying to figure out how to make an autocomplete list faster, as the database was too slow. I already had a functional test taking in search parameters and returning results. But there would be no way to write a test for the actual implementation of the indexed/faster search classes until I figured out a real approach. In the beginning, I had no idea if this would require a separate daemon process to do indexing, or if it could index realtime, or caching, or memoization, or where it might need to keep an index once created. These are just a couple of the unknowns. Once I figured out a workable concept, I wrote tests for those classes and functions. Then I refactored multiple times, altering the tests accordingly.
Your functional test was a test that allowed you to experiment. You designed the parameters and then altered the variables involved under the conditions of those tests.
You probably even "called your shot" and make guesses about what would be successful before you even approached the problem.
Then you wrote a test and saw whether your guess was right or not. If not, then you misunderstood something and you dug deeper.
