4 ms·

Roy osherove's naming convention served me well over the years: UnitOfWork_StateUnderTest_ExpectedBehavior https://osherove.com/blog/2005/4/3/naming-standards

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-tests.html https://osherove.com/blog/2005/4/3/naming-standards-for-unit...

jdkoeck 4y ago
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”
- oweiler 4y ago
  Or the even more common SUT (System Under Test)
  - jdkoeck 4y ago
    Ah, you’re right that SUT is the more common term, thanks!
- jmkjaer 4y ago
  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 4y ago
    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 4y ago
      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.
- delusional 4y ago
  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 4y ago
    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.

jdkoeck 4y ago

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”

oweiler 4y ago
Or the even more common SUT (System Under Test)
- jdkoeck 4y ago
  Ah, you’re right that SUT is the more common term, thanks!
jmkjaer 4y ago
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 4y ago
  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 4y ago
    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.
delusional 4y ago
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 4y ago
  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.