Having seen how you can use preview features in test code, the question is:
should you actually do this?
A few things should be kept in mind for answering that.
First of all, preview features are really that, a preview.
This means that details may change in future Java revisions.
Or, albeit unlikely,
such feature may even be dropped altogether,
should the JDK team arrive at the conclusion that it is fundamentally flawed.
Another important factor is the minimum Java language version supported by the JDK compiler.
As of Java 13, the oldest supported release is 7;
i.e. using JDK 13, you can produce byte code that can be run with Java versions as old as Java 7.
In order to keep the Java compiler maintainable, support for older versions is dropped every now and then.
Right now, there’s no formal process in place which would describe when support for a specific version is going to be removed
(defining such policy is the goal of JEP 182).
As per JDK developer Joe Darcy, "there are no plans to remove support for --release 7 in JDK 15".
Conversely, this means that support for release 7 theoretically could be removed in JDK 16 and support for release 8 could be removed in JDK 17.
In that case you’d be caught between a rock and a hard place:
Once you’re on a non-LTS ("long-term support") release like JDK 13, you’ll need to upgrade to JDK 14, 15 etc. as soon as they are out,
in order to not be cut off from bug fixes and security patches.
Now while doing so, you’d be forced to increase the release level of your main code, once support for release 8 gets dropped, which may not desirable.
Or you’d have to apply some nice awk/sed magic to replace all those shiny text blocks with traditional concatenated and escaped strings,
so you can go back to the current LTS release, Java 11.
Not nice, but surely doable.
That being said, this all doesn’t seem like a likely scenario to me.
JEP 182 expresses a desire "that source code 10 or more years old should still be able to be compiled";
hence I think it’s save to assume that JDK 17 (the next release planned to receive long-term support) will still support release 8,
which will be seven years old when 17 gets released as planned in September 2021.
In that case you’d be on the safe side, receiving update releases and being able to keep your main code Java 8 compatible for quite a few years to come.
Needless to say, it’s a call that you need to make, deciding for yourself wether the benefits of using new language features such as text blocks is worth it in your specific situation or not.