Is there anyway tom mock the super method call in a class using Powermock?
For example:
public void processRetrievedData() {
super.processRetrievedData();
}
is there anyway to mock “super.processRetrievedData()” ?
Thanks,
Rajan
Although this is bad practice, sometimes you need to mock out inheritance when your are working in an environment where there is no choice. For example, I needed to mock out super class methods in a Dialog Fragment in Android to isolate my unit tests. In your case, within your test use...
#PrepareForTest(ChildClass.class)
public class ChildClassTest {
#Test
public void testMethod() {
PowerMockito.suppress(PowerMockito.method(SuperClass.class, "processRetrievedData"))
// Run method and test
}
}
There are other overloaded methods listed in the API under the MemberMatcher class that are useful in other cases such as, method has parameters, there are additional inherited methods, etc. Hope that helps.
This is a terrible idea and a dirty hack.
If this is a part of your subject under test then you should never, ever do such things since you're testing the behaviour of that whole class and not only part of it.
If you really need to do sth similar you can extend the class and override the processRetrievedData method so that it doesn't call super - that way you stub that method.
Related
I'm looking at a control that must output raw HTML and provide rich design-time support.
How to create a custom server control, extend the WebControl class and override the Render method?
Can you provide an example?
regards,
Blanco
This will create a control that extends web control and overrides the Render method (though doesn't actually do anything with it.
public class TestControl : System.Web.UI.WebControls.WebControl
{
protected override void Render(System.Web.UI.HtmlTextWriter writer)
{
base.Render(writer);
}
}
As you can see this is a fairly trivial answer but complete so I suspect that you didn't actually ask the question that you intended to.
I am now moving from my code behind xaml dp binding to using CreateBindingSet, as I believe it will be easier to maintain on long run. Previously to confirm that I haven't missed any binding, I had a Windows Phone Test project with a generic test routine - that would parse a view for all the controls, and confirm that each has a correct binding. I did this using
element.GetBindingExpression(dependencyProperty) // from System.Windows
and that's worked beautifully - validating all my views.
But now as I am changing over, all these tests are failing. Has anyone any suggestions on how I can test same thing with when the binding is applied using CreateBindingSet and .Apply.
Thanks in advance.
Rana
Reasoning behind the Madness
Being a lazy sod, I dream of a day where my View would be shared across all platforms; until then, the following would do (I have most in place and working)
BoilerPlate class that would be shared between all platforms:
#if __IOS
... needed namespaces
#else ....
public partial class FirstView
{
private new FirstViewModel ViewModel
{
get { return (FirstViewModel)base.ViewModel; }
}
private void CommonBinding()
{
var set = this.CreateBindingSet<FirstView, FirstViewModel>();
// do common bindings
set.Bind(PageText).For(c => c.Text).To(vm => vm.PageText).OneTime();
set.Apply();
}
}
Then View in Touch would be:
public partial class FirstView : MvxViewController
{
public override void LoadView()
{
// create
}
public override ViewDidLoad()
{
CommonBinding();
}
}
In theory, Views in other platform would be almost similar; just different inheritance (MvxActivity with OnCreate, and OnViewModelSet)/(MvxPhonePage with xaml/alternative, and Loaded Event for binding).
Finally, a common testing way to ensure that all the items has binding set somehow. In my mind, until autoview is supported in wp8, it's just the way to have as much shared code as possible.
I have just started on droid, and trying to make the layout compatible with xibFree, which I have already used in my touch project. If this works, I can then have shared layout between droid and touch (perhaps I should be looking at autoView anyway)
I'm personally not sure what value these tests add that much value to your application - these feel like they are operating at a level of "duplicating code" rather than actually testing any functionality.
However, this is very much down to personal opinion, and if you do want this level of testing, then I think you could do this by:
Inherit a class from https://github.com/MvvmCross/MvvmCross/blob/v3.1/Cirrious/Cirrious.MvvmCross.BindingEx.WindowsPhone/WindowsBinding/MvxWindowsBindingCreator.cs
Override ApplyBinding so that you can capture at test time the calls made for each element
Register this class with ioc as the IMvxBindingCreator in your test harness
Use the captured lists of binding requests in your tests
I am having trouble incorporating graphical assets created in Flash with my Haxe code.
In the Flash IDE, I've created a symbol with the linkage name "MySprite". I compile this into assets.swf. I know that to use symbols in this .swf from my Haxe code, I need to add the following option when using the Haxe compiler:
-swf-lib assets.swf
I'd now like to write a class called "MySprite" which is associated with this symbol, like so:
class MySprite extends Sprite {
public function new() {
// ...
}
}
Basically, I'd like to achieve something similar to the technique presented in this tutorial:
package {
import flash.display.*;
[Embed(source="assets.swf", symbol="MySprite")]
public class MySprite extends Sprite {
public function MySprite() {
// ...
}
}
}
It's unclear from the Haxe documentation whether this can be done, or what the syntax is for doing it.
I think so, but I'm not sure, Haxe doesn't override classes from assets.swf with the classes you declared. There was a discussion about it on the mailing list (the old one, not in the Google groups), and this was the decision... I don't know why this decision was made.
You could still do it with SamHaxe. At least back in the days I was able to. Unfortunately, SamHaxe was abandoned, and if there are bugs or something not working as you need it - you are pretty much on your own. The good thing about Sam is that it's relatively small project. It's written in Haxe and I was able to build it from sources.
You could also try: http://code.google.com/p/hxswfml/ The project seems to be functional and the author used to reply to users. It might be a tad more complex though. I'm quite sure it was possible to do, but you will probably need to ask the author / figure it out yourself.
I know that by definition AS3 interfaces must be public, and the methods within them must be implemented as public as well.
I read this question and I suppose the answer is obvious if you want to have some classes choose whether or not to implement some methods, but have common base methods that must be implemented across all classes that implement either interface.
With that in mind, even with that 'private implementation' idea (which really isn't), is the best idea still to just explicitly define a private method for all classes, outside of the interface? The issue isn't forcing some classes to implement different methods, it's just the general visibility of those methods. I'm guessing the answer is "yes", but I figured I'd see if anyone had any insight.
Although AS3 doesn't support abstract classes , why not define a class to be used as an abstract class and have it implement that interface and define the non public methods inside that class.
interface IThing {
function thisMethodIsPublic():void;
}
public class ThingAbstract implements IThing
{
//throw an Error to avoid calling the class directly,
//this class needs to be subclassed
//and this method overridden
protected function thisMethodShouldOnlyBeVisibleToCertainClasses():void
{
throw new IllegalOperationError
('this method should be overriden in a subclass');
}
public function thisMethodIsPublic():void
{
}
}
To put it simply as an example,
public abstract class AbstractFellow {
protected Thing buddy;
....
public class ConcreteFellow extends AbstractFellow {
public void someMethod() {
buddy.doSomething();
//OR
buddy = somethingElse;
//OR
somethingElse = buddy;
}
}
Is this bad practice?
Opinions vary. My opinion is that even in abstract classes, using private members and protected accessors (i.e. protected getBuddy()) is a better practice.
It allows for the same things encapsulation always allowed: to contain the logic of obtaining the "buddy" object in the super-class, and allowing you to change that logic without breaking all inheriting classes.
The super-class might not expect buddy to be changed, either. For example, you might want to unregister listeners or do some other cleanup when that happens - having a setter method helps achieve that.
In addition, it obviously allows you to have Buddy as a read-only member (since you can provide only a getBuddy and no setBuddy), something that is not as easy to accomplish with a member (you can always set it to be final, but then you prevent the super-class from changing it, too!)
It depends on you domain model and why you creating and abstract class. If you are defining your interface with it and want abstract class to keep some functionality it`s ok.
If you are just setting all the fields protected and then reusing them in your child classes. Well it depends, but I think a better way should be found. And it seems not very clear for your future reader to get data in the base class and all it's behavior in child classes.
If you do not need base class ability to implement methods (and you do not need to store any functionality in your base class) maybe it`s a better choice to implement an interface with every of these child classes.
If you use some of base class inner fields it seems natural to me and it's ok. Just if you are using some of them in your child classes for similar things you can implement a template method and enjoy with overriding only the parts you really need to override.