The only way is to embed the test in your production class, which one
generally doesn't do.
If your test class is separate from your production code then no, you
cannot directly test a private method.
That said, there is one trick you can use to get _some_ of the desired
effect. If your private method contains a lot of complex business
logic, try splitting the most complicated bits out into one or more
static methods. That is, methods that neither rely on nor change the
state of your object, but only contain logic to do calculations. It's
safe to then make those static methods public, and then you can test
them.
For example, I have an Invoice class that contains a bunch of fancy
logic for calculating due dates. I can test that logic indirectly from
the outside by creating invoices with various terms and then examining
the due dates to see if they're correct.
Or, I can take all of that fancy business logic and put it in some
static methods: I pass them everything they need, they calculate a due
date and return it. I then call those static methods from my Invoice
class in order to calculate due dates, and I can also now make them
public and test them from NUnit without any risk to the internal state
of my Invoice objects.