Dan North answered this question with BDD in 2006, this might interest you:
To sum up the idea, we need a paradigm shift and stop thinking about tests but more about specifications/behaviour.
When we write our test we want first to write a specification of the object we are going to implement.
By following this philosophy we quickly find out that our "test" methods name should actually be a sentence that describes an expected behaviour. That's because we want to read a specification and not tests.
We also want to keep our "tests" methods name short, because it's easier to read and enforce the idea that the object under specification should have one Responsibility (SRP).
That's why we encourage the one assert per test guideline.
As an example if we would write a specification for your Profiler, the test method name could be:
Which reads nicely as a specification. If you were to put all your asserts in one test then the specification would read as a long sentence like
Which is not really nice, specially when the test fails you wouldn't be able to figure out precisely for which reason it's failing.
If you come back to your specification weeks later, you should be able to understand what the object is supposed to do by just reading your "tests" methods names.