Availability groups taking time to change states I created a 2 node AG setup as a POC today and when I tried to do an automatic failover by stopping the sql server service on the primary node, the one in the secondary went into resolving state and it took a long time for it to become a primary AG.

Does it have to do with networking issues? I also want to know if it is a good practice to have a separate network interface for the heartbeat network. When I go to the networks in WFSC I only see "cluster and client" and I assume it also includes the heartbeat.
I created a 2 node AG setup as a POC today and when I tried to do an automatic failover by stopping the sql server service on the primary node ...


Just as others have pointed out in the comments section, this isn't a good way of testing as you've nicely and cleanly taken the service down. I mean, it is a great test if your disaster case is "someone shutdown SQL Server nicely", however outside of that it doesn't help much.

Having a two-node cluster also isn't very helpful for testing HA (or production) as there are just two possible nodes. While you can argue the usefulness of this setup one way or another based on certain factors, you won't really get to experience AGs until you have 3 or more nodes. This is mainly to do with 2-node clusters being special cases since there are so little resources. 


  ... the one in the secondary went into resolving state and it took a long time for it to become a primary AG.


Resolving, in AG terms, means it is trying to find and connect to the primary. Since you've shut it down nicely, it'll take some time (assuming the cluster has quorum and the failover policy has been met) to fail.


  Does it have to do with networking issues?


Nope.


  I also want to know if it is a good practice to have a separate network interface for the heartbeat network.


No such thing as a "heartbeat" network since Windows Server 2008+. The cluster will decide which route to take.

What do you really want?

If you want to see how long automatic failover takes then you'll first need to figure out what scenarios you'd like to test. Here are some examples:


OS Disk fails
Cluster partitioning
Data disk fails
Out of memory
Bugcheck
log disk fails
Overwhelmed disk
slow networking
windows patching
sql patching
server power failure


You can add more, but for each possible issue there will be a different amount of time it takes.

The amount of time is roughly:

total = Detection + Mitigation + Redo Queue drain + Undo

Each of the above will have different detection and mitigation times, but the redo and undo should be roughly the same for each test. So, at the end of the day, really you're testing detection times.

If you only care about how long it takes to do a failover, then run: ALTER AVAILABILIY GROUP MyAG FAILOVER on the new primary. Time it. That's how long it takes.