I think you may still have a slight misunderstanding of the SOLID principles.
The validation object is type hinted on the constructor. If I attempted to pass any other object (one that does not implement the interface) I would throw an exception. The test in this case is to test the actual State Transition class. I have other tests at the level these classes are called. These are the tests that would pick up if I was passing an incorrect interface.
I could have type hinted against a concrete implementation of a validation class but we should avoid doing that and code to an interface where possible.
I understand the purpose of the interface, what I'm seeing is that code is changing and it's behavior is not expected to change. The interface does not define behavior, the validation class tests do, but I need to know the activation behavior has not changed. And this code change, by design, decouples the validation logic from the taking action logic.
The purpose of my comment is to get you to think about the implications of following those principles, especially when the modified code had no reason to change other than to meet those principles.
This comment sounds more like you don't want to defend what you did and hope that generic explanations of how to write code will explain why it is OK to modify untested code. I can tell you right now the first advice will be to write a unittest to test the existing code before you refactor.
As has already been explained clearly in the post - it is impossible to write a unit test for the original code because dependencies were instantiated. How does one write a proper unit test for a piece of code that has hard-coded dependencies.
Your assumption that the code was not covered is interesting though because it actually was covered by feature/integration tests. The feature tests still passed after the refactor by the way. The feature tests took the calling code for the State Transition class - passed with concrete validators and data from the database and then verify that after we call the transition end point the actual record in the DB has transitioned as expected. But all of that is completely out of the scope of the original blog.
Your comments have read like someone who is learning about proper software architecture. The end points you have arrived at differ wildly to your initial (incorrect) assumptions. I will not respond to further comments about this now. It has proven pretty fruitless and I once again suggest you brush up on SOLID principles.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think you may still have a slight misunderstanding of the SOLID principles.
The validation object is type hinted on the constructor. If I attempted to pass any other object (one that does not implement the interface) I would throw an exception. The test in this case is to test the actual State Transition class. I have other tests at the level these classes are called. These are the tests that would pick up if I was passing an incorrect interface.
I could have type hinted against a concrete implementation of a validation class but we should avoid doing that and code to an interface where possible.
I understand the purpose of the interface, what I'm seeing is that code is changing and it's behavior is not expected to change. The interface does not define behavior, the validation class tests do, but I need to know the activation behavior has not changed. And this code change, by design, decouples the validation logic from the taking action logic.
I think you need to go back and revisit your software engineering fundamentals.
The purpose of my comment is to get you to think about the implications of following those principles, especially when the modified code had no reason to change other than to meet those principles.
This comment sounds more like you don't want to defend what you did and hope that generic explanations of how to write code will explain why it is OK to modify untested code. I can tell you right now the first advice will be to write a unittest to test the existing code before you refactor.
As has already been explained clearly in the post - it is impossible to write a unit test for the original code because dependencies were instantiated. How does one write a proper unit test for a piece of code that has hard-coded dependencies.
Your assumption that the code was not covered is interesting though because it actually was covered by feature/integration tests. The feature tests still passed after the refactor by the way. The feature tests took the calling code for the State Transition class - passed with concrete validators and data from the database and then verify that after we call the transition end point the actual record in the DB has transitioned as expected. But all of that is completely out of the scope of the original blog.
Your comments have read like someone who is learning about proper software architecture. The end points you have arrived at differ wildly to your initial (incorrect) assumptions. I will not respond to further comments about this now. It has proven pretty fruitless and I once again suggest you brush up on SOLID principles.