If you want to track the testing distribution, I would strongly recommend running a mixture of testing and unstable: that will allow you to pull in updated packages from unstable if necessary (e.g. for security fixes). To do this, ensure both testing (named as such, rather than the specific release name) and unstable are available in your configured repositories; then set up pinning, e.g. in
Pin: release a=testing
Pin: release a=unstable
This will result in packages being tracked in testing if they’re available there, unstable if they’re not, or if they’re installed in a version newer than what’s available in testing. As Debian transitions from preparing Stretch to preparing Buster, and packages migrate from unstable to testing, your local installation will progressively start tracking Buster instead of unstable. This avoids needing to downgrade anything, and hopefully should result in a Buster setup in relatively short order after Stretch is released since testing and unstable haven’t yet diverged too much. (This will change very quickly after Stretch releases, so make sure you set this up before then.)
This kind of setup avoids issues with packages disappearing from testing for sometimes long periods. It also makes it easy to track security uploads to unstable, using Paul Wise’s patch to
debsecan. I’ve been running this on my main setup for years without issue (but then again, I’m intimately familiar with the inner workings of Debian). The annoyances Fahim mentions in his answer mostly concern new installations of packages, which can be troublesome in pure testing; in practice they’re not much of an issue on a running system.
The usual caveats to running testing and/or unstable apply. You should make sure you’re familiar with the best practices. In particular, make sure you’re aware of all the changes
apt-get wants to make on upgrades before letting it loose.