Stack implementation with a linked list
using namespace std; // TESTING


Judging by your comment, I'm guessing you're aware about the problems of exposing namespace members in the global scope. But did you know that you can using namespace inside scopes other than the global? It is fine if in your unit tests you want to expose the std stuff to make the code less verbose, but do that in the shortest possible scope then, in this case, inside main():
int main()
{
    // Make an exception since this is a unit test and expose
    // the whole Standard Library inside main(), so we don't have 
    // to std:: qualify everything.
    using namespace std;

    // same as before ...
}



 cout &lt;&lt; &quot;Destroyed&quot; &lt;&lt; endl;  myStack.~Stack();


Very unusual for you to be calling the destructor for myStack. A destructor is called automatically when an object goes out of scope or is deleteed. There are very few cases where a programmer would manually call a destructor, those are not present here. If you just wan't to ensure the object is destroyed before the end of main(), to log some stuff, wrap its declaration inside a new scope. E.g.:
int main()
{
    {
        Stack&lt;char&gt; myStack(3);
        ...
    } // &lt;== ~myStack() called here
}

This way you won't risk ending with a half destroyed object in your hands.


template &lt;typename T&gt;
T Stack&lt;T&gt;::top() const
{
    if (head != nullptr)
    {
        return head-&gt;data;
    }
    else return NULL;
    //          ^^^^ problem here!
}


That will not work for a T type that is not a pointer or integer. NULL can be assigned to integers because it is usually implemented as #define for 0. That's one of the reasons why you should use nullptr whenever possible (C++11). If you had used nullptr, your test with T=char would have failed and you would have noticed this problem.
The usual convention for a generic stack is to throw an exception if you try to access the top for an empty stack. Returning a &quot;default&quot; value is less generic and also makes it harder for the caller to detect errors. Returning a default also requires the type T to be default constructible, so don't do it.
Same goes for popping on an empty stack. Right now you are not generating any errors. You should consider throwing and exception. Deriving a StackUnderflow exception type from std::runtime_error might be a good idea. Then you can extend the concept to a StackOverflow error when trying to push to the bounded stack. Granted that you can do with a simple std::runtime_error, but defining custom exception classes is a nice exercise if that's your point for writing this implementation.


cout &lt;&lt; &quot;push: &quot;; myStack.push('H'); cout &lt;&lt; myStack.top() &lt;&lt; endl;


Don't pack that many statements in a single line. People read shorter columns of text much faster. But not just that, mixing several statements together makes it a lot easier for a quick read to miss some important part of it. Put each statement in its own line.
cout &lt;&lt; &quot;push: &quot;; 
myStack.push('H'); 
cout &lt;&lt; myStack.top() &lt;&lt; endl;


Not a huge thing, but usually this kind of data structures uses std::size_t for things like size and capacity. That's an unsigned integer, which makes sense since the stack size is not meant to be negative, however, there is some discussion about avoiding unsigned integers, so that's up to you to decide if it is worth it.

Last thing is a bit of a big subject, which was introduced with C++11, called move semantics. Your code does some unnecessary copying of data on push and StackNode's constructor, which might affect performance when T is something other that a native type or pointer. I'll leave you with a couple references you can read to further learn about this:

SO: What are move semantics?

cppreference.com: Move constructors.