How To Prevent Live Servers From Detecting a Forced Failover?
Snapshot
Assuming the use of VMs, take a snapshot of the DR server after the source site is disconnected.  I might recommend shutting down the server first just so the snapshot is in a good, clean state.  After the DR testing is done, shut down the DR server and then revert it to the snapshot.  This is easy and cheap.  The only downsides are that the source site is unprotected during the test, and the DR node may be a little slower due to the snapshot depending on your storage infrastructure.  Oh, and your primary will have to have enough disk space to queue database replication until the sites are reconnected.

Use a Clone
Assuming that you're using VMs and have adequate disk space, clone the DR node, shut down the original DR node, and do the testing on the clone. When done, delete the clone and bring the original DR node online.  This solves two problems: 1) You don't have to resynchronize the entire database(s), and 2) You don't have to evict/join cluster nodes.

The downside of this approach is that during the time of the testing, the primary server has to queue all of the data, so transaction logs may get quite large.  In the test you performed, this was occurring so you apparently had enough disk space for your logs that it wasn't a problem.

Use Even More Clones
Some organizations create a "bubble" network at the DR site that cannot communicate with the production DR network.  Then infrastructure servers (domain controllers, DNS, etc.) are cloned and the clones are brought online in the bubble.  Then the other servers that need to be part of the DR test are cloned into the bubble.  This allows you to keep your real DR servers online and functional during the DR test.  Other than truly failing over everything, this is about the safest, because what happens if the primary site gets destroyed 5 hours after the DR test starts?  If you've disconnected the sites, you lose 5 hours of data.

The downside of this, of course, is that it can become a massive undertaking and require a lot of staff time, hardware, etc.

Evict and Rejoin
As mentioned in the comments above, you can evict the DR node from the cluster before the DR site is reconnected, and then rejoin it back to the cluster and add the node back to the availability group.  This is fairly simple and requires the least hardware, but it does have the downside of leaving your primary site unprotected during the time of the DR test.