[splittingTimes]

Roy osherove's naming convention served me well over the years:

UnitOfWork_StateUnderTest_ExpectedBehavior

https://osherove.com/blog/2005/4/3/naming-standards-for-unit...

[jdkoeck]

Why prefix with “unit of work” when the its name already appears in the test class name? This is redundant.

PS: by the way, “unit under test” is probably a better name than “unit of work”

[delusional]

That's answered in the linked post:

>You usually have at least a number of tests for each method you are testing, and you are usually testing a number of methods in one test fixture (since you usually have a test fixture per class tested). This leads to the requirement that your test should also reflect the name of the method begin tested, not only the requirements from it.

[jdkoeck]

Ah, I get it now, thanks. I think I’d rather wrap the test method in an inner class named after the method-under-test, but not all testing frameworks allow for inner classes.

[jmkjaer]

A unit of work is not necessarily a class, but rather its methods. The linked article states that

> A unit of work is a use case in the system that startes with a public method and ends up with one of three types of results (...)

I use the same naming as well, and I really like it.

[twodave]

It took me a few seconds to parse what UnitOfWork meant in this context because that’s also a pattern for carrying e.g. database transactions through to different dependencies. E.g. in C#:

    using var uow = UnitOfWorkContainer.Begin();
    await SomeDep.Save(foo); // internally uses the uow's transaction
    await SomeOtherDep.Save(foo2);
    uow.Complete();

[jdkoeck]

Yup, that’s what a unit of work is to me too. It’s a well-known design pattern, so overloading that term for testing seems ill-advised.

[oweiler]

Or the even more common SUT (System Under Test)

[jdkoeck]

Ah, you’re right that SUT is the more common term, thanks!