DFS algorithm + unit test
The implementation of depth-first traversal is correct.
But there are several elements of this program and tests that could be improved.

Prefer empty collections over null values

When the input graph is empty,
it would be better to return an empty list instead of null.
Collections are used for iterating over its elements.
When a collection variable can be null,
that's troublesome, because before you can iterate over it,
you have to check that it's not null.

Constraints and limitations

The implementation will only work with directed graphs without cycles,
otherwise you will have an infinite loop.
This is important to include in the description.
A common follow-up question at an interview is how to make it work in graphs with cycles.

Weak tests

The test knows too much about the implementation.
There are 6 possible valid depth-first traversals of the example graph,
and the test knows exactly which one to expect.
It all comes down to the evaluation order of neighbor,
in your implementation it's the reverse order that they were added.
Either this implementation should be documented,
or the test should not depend on it.

The example graph is not a good choice to demonstrate depth-first traversal,
because A F E B C D would be valid both as depth-first and as breadth-first traversal.
A more expressive example would be:

    A
   / \
  B   C
 /     \
D       E


With this example all depth-first and breadth-first traversals would be distinct.

Lastly, a technical detail,
instead of comparing the elements of a list one by one to values,
you could compare entire lists, which would be a lot easier to type.

List&lt;string&gt; expected = new List&lt;string&gt;(new string[] { "A", "B", "C", "D", "E", "F" });
List&lt;string&gt; result = TraverseDFS(root);
Assert.AreEqual(expected, result);


Don't provide setters if you don't really need

The fields of GraphNode are never modified,
therefore the setters are unnecessary.