That all makes sense to me. I like the clear distinction between tests and integration tests based on the name of the projects, and I like the clear language in the naming of the tests.
When you start teaching your colleagues who are a little greener to unit testing, make sure they understand the concept of writing code that is testable. Writing code that uses good dependency injection patterns is a good practice for implementing any testable system.
If your colleagues are really sharp or if they have exposure to testing and mocking, they will maybe ask how to mock sealed classes, or how to stub out behavior from abstract classes they are extending, and why it may not be the best idea to code themselves into a testing trap by following those patterns themselves.
That all makes sense to me. I like the clear distinction between tests and integration tests based on the name of the projects, and I like the clear language in the naming of the tests.
When you start teaching your colleagues who are a little greener to unit testing, make sure they understand the concept of writing code that is testable. Writing code that uses good dependency injection patterns is a good practice for implementing any testable system.
If your colleagues are really sharp or if they have exposure to testing and mocking, they will maybe ask how to mock sealed classes, or how to stub out behavior from abstract classes they are extending, and why it may not be the best idea to code themselves into a testing trap by following those patterns themselves.
I will give a try to explaining sealed classes are not so easy to test. Maybe short introduction into wrapping would be enough here?
I would say so.