Probably very simple, but can't figure it out.
How can you use methods from tests/_support/AcceptanceTester.php inside your helper modules?
For example when I'm in tests/_support/Helper/Acceptance.php I cannot reference any of the methods in tests/_support/AcceptanceTester.php
I'm assuming because one is an actor and the other is a module?
I read https://codeception.com/docs/06-ModulesAndHelpers but I still don't understand how this works.
Update
Saw a discussion on github that deals with this situation and it was suggested to use StepObjects
I managed to put both helper methods and actor methods into a StepObject class method, but that still doesn't work. It doesn't allow me to execute both from one place.
After a few hours of trying to find an 'elegant' solution to this problem such as using StepObjects injecting dependencies etc. it's much easier to just pass the $I object to whichever helper class method you're using..
It's more verbose, but it works.
If anyone has a better solution, I'll gladly accept it instead.
Related
I started learning the dart language. when I heard the term Helper Class. I didn't get any clear answer.
Please tell me about
What is the meaning of the Helper Class?
For which purpose they are used
Thank you so much to the kind community. :)
In simple words Helper class is like a warehouse where you can put commonly used operations for other classes. So whenever other classes will need them they can access them.
Imagine you have some code which is commonly used in your app. So there are two ways to use that code.
To write the same code again and again. (Which no one wants and prefers)
To put that code somewhere and call it whenever you need it. And this is a situation where helper class come in to play.
Below are some main objectives behind its creation:
A helper class is created to make code more readable and clearly organizable.
They help to eliminate boilerplate code as they contain commonly used functionalities.
The other goal behind its creation is to provide a common functionality to other classes. In helper class, you can move some methods, variables, and operations, which are commonly used in other classes. So it helps to make your code more organized, maintainable and readable to others.
I hope it helps you. :)
Since I've started using TDD I've been firmly convinced that it's a great way to write good correct pattern compliant code, without forcing my design decisions.
And I found this true in 80% scenarios, but I have problems when it comes to test certain tipe of objects which, for some reason, wrap and hide an object inside the implementation.
To give you an example let's think of a MyLocationManager objects which gives a common interface to my objects to be used, and wraps inside an NSLocationManager.
When I want to test such an object I have to supply a mock NSLocationManager of course.
I have of course the property/constructor injection method, but this means adding a property, or a constructor parameter, with an objects that I simply want to hide from the other objects: I've created MyLocationManager to wrap and hide NSLocationManager, why should I be exposing a property just to test it?
A method I've found which is pretty straightforward is to method swizzle NSLocationManager's methods, so I can exchange the actual implementation of a method with a mock one, but this seems pretty unclean and I don't know how safe it is.
As far as I can understand, there might be a Demeter Law's violation in not exposing a property constructor, but on the other hand, I think that in objective-c some flexibility on this pattern is accepted.
So my question is, there should be any way I'm not clearly seeing to adopt property/constructor injection, or method swizzling is a commonly used practice?
Are there any other techniques for this scenario adopted that I should better use?
On a footnote:
This problem is true even with objects that wraps networking code and classes like NSUrlSession.
Well, at one point the testing set-up can be more complicated than the code to test, so one might remember, what testing was invented for.
I think a pragmatic way is, to expose the property you need only in a separate header containing a separate class continuation.
After a long time of Test Driven Development experience, I find this old question of mine pretty simple to answer.
For some reason I was thinking that property injection and dependency injection where to avoid to mask something.
I simply don't think this anymore.
In the previous scenario of my original question the right answer from present-me is:
You have to expose the dependency of NSLocationManager, maybe providing a constructor injector method, and a convenience constructor method, to initialise the location manager with NSLocationManager.
There is no real need to hide the dependency even if it is a wrapper class, because in the exact moment you find yourself with the need to swizzle some methods, you're hacking the "internals" of your object and tweaking it without testing the interface, modifying the runtime behaviour in an uncontrolled manner.
If you wanna swizzle, swizzle ahead, but it's not the right choice.
I am writing a class that has many class variables. So I am declaring the variables as static in my .m file and before #implementation statement, with setters and getters for them as class methods. Is it a good idea to do this for lets say more than 10 class variables? Or is there a better alternative to do this?
Without more information that's a tough call. Technically working - yes.
I know many people don't like singletons, but maybe this is one of the good use cases for it?
Maybe you find that configuring one of those classes, or now objects, really doesn't have to be a singleton at all?
Just because there is only one instance of a given class doesn't mean in cannot be a "normal" class.
Class variables often mystify your state all over your code base and make debugging and code reuse a pain. Let alone multi threading.
Edit: Given your usecase as described in a comment to another answer, I'd go with a singleton, i.e. a 'SoundPlayer' class. '[[SoundPlayer sharedInstance] playCoolSound];' is easy, and you get proper instance variables there, too. And you can always exchange it for another class if needed (think test cases etc.).
Well, I can guarantee that the computer will have no problem with it. They're pretty good with large numbers.
Without knowing more about your situation, it's hard to say. It does sound, though, like you're potentially going about it in a way that isn't optimal. It's good that you followed your intuition and are asking about it. Perhaps you should modify your question (or ask a new one and link it here) to talk about what you really want to accomplish, and then we can help.
As far as I can see there are two main principles how to deal with application-wide role player objects like a root model object (in MVC context):
create the object and pass it through the object tree (e.g. in the constructor)
provide it as a singleton or other global variable technique
The first approach seems to be cleaner because the dependencies are better visible but there is a lot of additional work to do (parameters, class variables,...).
What do you prefer?
Edit: The first technique also uses only one instance but it is provided by passing the object and not by a static function
I prefer run singletons' method getInstance() as constructor parameter - bake two birds with one stone ;)
This is where dependency injection can help out. Having to explicitly pass all the correct dependencies manually to an object whenever you create one can be a pain and perhaps somewhat error prone. A decent dependency injection container can help to automate this process and is actually easier to use than singletons.
The Symfony2 framework is a modern example:
http://symfony.com/doc/current/book/service_container.html
I think passing as parameter is a little more memory-efficient, easier to debug, but need a some additional work.
I prefer to use singletons only when i really need it (like database sessions, write to file etc.).
It really depends on project type, language, budget, size of project etc. There is no "universal" answer.
I want to implement IoC in my application, I've few queries regarding that
While binding Interfaces to Classes, i want to specify the scope of the object
While resolving the class object, i want it to resolve all the dependencies automatically
While passing the vaue type arguments to my binding, how could i use factory methods to pass the value as i don;t want to use constructor arguments for the same
I am using IoC in my WCF application, if i am doing something wrong please suggest some better approch to get best results
Thanks
First of all, be sure to look at Ninject.Extensions.Wcf including the examples and the fact that you put a custom factory in the .svc file.
Then just issue Bind<>().To<>().InXyzScope().WithConstructrorArgument(...)calls in your Module Load.
You havent asked a structured question though so I doubt anyone else is going to be able to make a better stab at an answer than this, which probably isnt going to make you happy...