Request for Feedback: Testable Services with Inverted Component Dependencies

[Rusi Filipov]

Dear Uncle Bob,

valued group Members,

inspired from Uncle Bob's Clean Architectue model I have written a description of a pattern for designing and testing services on the component level. 

https://github.com/rusio/testable-services

It is based from a downsized application of the Clean Architecture model on a small project, with just a single interactor and three boundary interfaces in the core application. 

Nevertheless components follow throughout the Dependency Rule and a suite of component/integration tests was used in the real project throughout development in order to test the components at the API level.

So while the text has just emerged recently, it would be nice to hear your oppinion and any feedback on it.

PS: There is also a small test example in C#, showing how one of the components might be tested.

Best regards,

Rusi

[Sebastian Gozin]

I'm seeing a lot of things I also see in my own applications.

One thing perhaps.
Is https://github.com/rusio/testable-services/blob/master/VideoConverter-CSharp/IntegrationTests/HttpConnectorIT.cs the example?

Because when I have a component A which uses interface I which is implemented by component B then I would probably test by wiring component A with component B directly provided A and B both live in the business logic space even though I'd deploy them as their own microservice. Making them microservices would be a case of implementing I to invoke TCP and implementing a TCP server which invokes I but this time an instance of B. (proxy pattern?)

That way I can focus on the business rules and how those 2 components interact without an embedded SQL or HTTP server.

If I wanted to test the TCP bridge I think I'd probably spin up an embedded TCP server. Invoke it with that TCP implementation of I and wire the server with a spy implementation of I which asserts the original invocation matches what I received on the server.

[Dave Schinkel]

I realize this is totally a matter of preference and not a huge deal, but just an observation and suggestion to help reduce some redundancy and verboseness in your tests.

I used to do exactly what you did in C# when I first started writing tests... until someone who had done TDD a long time said to me one day, why are you adding comments in every test!  Then I said well...because it helps me...then I realized it was really just clutter.  So...

1. You may wanna get in a habit of leaving out //arrange, //act, //assert comments completely. 

and..  

1. You also might wanna remove 'Given', 'When', 'Then' which just adds repeated clutter to your naming...but You'd have to throw away Roy Osherove's naming convention (which I ended up doing later on).

Here's a different style in case you're interested...taking one of your tests:

GivenStartedServer_WhenRequestArrives_ThenServerResponds

GivenIdleProcessor_WhenStatusIsQueried_ThenStatusIsIdle()

Try something like this

SomeServiceTest.cs

ItCanRespondToARequest();

           ReturnsIdleStatusWhenProcessorIsIdle();

            

...etc. 

Since the tests would be in a service test class, the context of that test class implies what's being tested..so you wouldn't need to include the word "service" or "server" or whatever in the test names.

or.. if you like it, keep it.  :)  Just wanted to throw the idea out there though.