Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Use default name for parts #107
It simplifies its instantiation and, therefore, unit testing them:
WDYT @timriley ?
Further simplification could be made by using
Thanks for taking the time to think through this, @waiting-for-dev :)
Firstly, I think you might've tweaked the wrong method? I think you might be wanting
Either way, I'm not sure about making the name optional, since it's used when building scope locals when rendering or building scopes. Leaving the name out e.g. in tests, when a name is always provided in the normal course of Part initialization, feels like it would make the tests less authentic and therefore less helpful. Does that make sense to you?
On a related note, I do still have an open issue about somehow supplying testing helpers (whether that's code we can ship in the gem or simply examples that can be copy/pasted, I'm not sure yet), but perhaps that's an opportunity to improve the ease of testing parts, rather than modifying their core code?
Thanks for your feedback @timriley
Oops, apologies... Terrible, I certainly prepared this PR to quick... Besides tweaking the wrong method, I made my tests working with last released version, where
I see your point. However, I've conflicting ideas with it. You are right with the fact that providing defaults would make the tests less authentic. But it is also true that the actual scenarios where parts are used are always in orchestration with other components. In a unit test, which is just another API consumer, it would make sense to be able to treat the part in isolation. If instead of being a functional object parts were just a module (with a pattern different that decorator, of course),
To be honest, except for scenarios where complexity is high, I see the need of testing helpers as a code design smell. If there isn't a very good reason, I think objects should be always easy to instantiate. In fact, it is one of the main reason, together with state avoiding, why I think
If you agree with me, I can think of two possible solutions: