In PHPUnit, I want to use methods like verifyText() with an optional message as the last parameter, like I do with assertStringEquals($expected, $actual, $message). It doesn't seem to work. Am I missing something?
I would tell myself to read the code, but I tried and I can't even figure out how any of the verify() methods get called. It must be some __call() function but I don't see it. So that's my follow-up question, how do the verify() methods get called? Then I could override them if I want.
I'm exploring the same question, albeit in the context of Selenium.
I found, grepping the source, an array $autoGeneratedCommands, which is set up in SeleniumTestCase/Driver. The mechanism here implements/maps verifyTextPresent() by a call to verifyCommand(), which calls assertCommand(). Subsequently one of the family assert*() is called... omitting the message in the call. This seems like an inadvertant feature to me. Well, coded bug.
Related
I am generating a class in ByteBuddy.
As part of one method implementation, I would like to set a (let's just say) public instance field in another object to the return value of a MethodCall invocation. (Keeping the example public means that access checks etc. are irrelevant.)
I thought I could use MethodCall#setsField(FieldDescription) to do this.
But from my prior question related to this I learned that MethodCall#setsField(FieldDescription) is intended to work only on fields of the instrumented type, and, looking at it now, I'm not entirely sure why or how I thought it was ever going to work.
So: is there a way for a ByteBuddy-generated method implementation to set an instance field of another object to the return value of a method invocation?
If it matters, the "instrumented method" (in ByteBuddy's terminology) accepts the object whose field I want to set as an argument. Naïvely I'd expect to be able to do something like:
MethodCall.invoke(someMethod).setsField(somePublicField).onArgument(2);
There may be problems here that I am not seeing but I was slightly surprised not to see this DSL option. (It may not exist for perfectly good reasons; I just don't know what they would be.)
This is not possible as of Byte Buddy 1.10.18, the mechanism was originally created to support getters/setters when defining beans, for example. That said, it would not be difficult to add; I think it would even be easiest to allow any custom byte code to be dispatched as a consumer of the method call.
I will look into how this can be done, but as a new feature, this will take some time before I find the empty space to do so. The change is tracked on GitHub.
Just wondering if you can mark a method as pending to implement in pharo, like you can do in java using "todo"
I'ts really hard for me to keep track of what's complete on pharo without something like that
Methods whose implementation is still pending should send the notYetImplemented message like this:
methodImNotSureHowToImplement
^self notYetImplemented
if the unimplemented message gets sent anyway, it will signal a NotYetImplemented exception which will know the offending selector, #methodImNotSureHowToImplement in my example.
Note also that this will make it easy finding all methods that need to be implemented as senders of #notYetImplemented.
The implementation of #notYetImplemented is straightforward, thanks to the existence of NotYetImplemented.
notYetImplemented
"Announce that this message is not yet implemented"
NotYetImplemented signalFor: thisContext sender selector
Note also that NotYetImplemented is one of the subclasses of SelectorException which model several situations of similar kinds:
SelectorException
NotYetImplemented
PrimitiveFailed
ShouldBeImplemented
ShouldNotImplement
SubclassResponsibility
I found the solution for this by myself 2 days after asking about it, almost accidentally, just using the context menu option jump to test method over a method without any test. Pharo automatically generated an empty test with this:
self flag: #toImplement.
self assert: false`
the first line, which can be used not only on tests, gives me the behavior I expected as it automatically categorizes the method containing it on a flags category marked with a big "!" allowing to easily check at glance which methods are pending.
The second line forces test to fail and be shown on yellow which is pretty useful because if it's empty it will pass and be shown on green, probably leading to believe it's already done when is not the case. A similar effect can be achieved just using self notYetImplemented
I would probably start doing something like this with my incomplete methods:
MyIncompleteMethod
self flag: #toImplement.
self notYetImplemented.`
you also can use pragmas to mark such methods
As Smalltalk provides the origin of agile development, let me provide a different answer. In a failing unit test. As you are not supposed to have a lot of those, it automatically provides the pressure to limit work in progress (the number of open #toDo's).
I write on Groovy and use Spock framework for testing.
Some time ago, IDEA completely supports Spock.
When I've writing the code inside feature (test method) in where-block something like this:
with(someObject) {
intField == 1
...
}
IDEA correctly recognize the someObject and understand that intField is field of the object, also, it was offering me other fields of the object. So, inside Spock's with() block I've felt like inside any closure from DefaultGroovyMethods (with{}, each{}, find{}, etc.), but haven't need to use explicit it param.
(So, I's writing with(someObject) { intField == 1 } what is the same is someObject.with { assert it.intField == 1 }.
After a moment IDEA missed Spock's with() method support.
Now, it don't recognize the class of the parameter (ex. someObject) in think that it's object of Object class. Any fields inside closure don't be recognized. Explicit it usage didn't help.
After some IDEA update everything have repaired, but after reboot the problem has come back.
Does anybody know how to fix it??
I'm using the last version of the IDE - 2018.2
I just tested this out with 2018.1 and have the same issue as you. I didn't run the code but I am fairly certain that the code would be recognized and executed. This to me looks like a bug with Intellij, and it might be worth it to submit a bug report in their ticket tracking system.
I am working on a VB.NET project which requires the extensive used of Unit Tests but am having problems mocking on of the classes.
Here is a breakdown of the issue:
Using NUnit and Rhino Mock 3.6
VS2010 & VB.NET
I have an interface which contains a number of methods and an Event.
The class which implements that Interface raises the event when one of the methods is called.
When I mock the object in my tests I can stub methods and create/assert expectations on the methods with no problems.
How do I configure the mock object so that when a method is called the event is raised so that I can assert that is was raised?
I have found numerous posts using C# which suggest code like this
mockObject.MyEvent += null...
When I try this 'MyEvent' does not appear in Intellisense.
I'm obviously not configuring my test/mock correctly but with so few VB.NET examples out there I'm drawing a blank.
Sorry for my lack of VB syntax; I'm a C# guy. Also, I think you should be congratulated for writing tests at all, regardless of test first or test last.
I think your code needs refactoring. It sounds like you have an interface that requires implementations to contain an event, and then another class (which you're testing) depends on this interface. The code under test then executes the event when certain things happen.
The question in my mind is, "Why is it a publically exposed event?" Why not just a method that implementations can define? I suppose the event could have multiple delegates being added to it dynamically somewhere, but if that's something you really need, then the implementation should figure out how that works. You could replace the event with a pair of methods: HandleEvent([event parameters]) and AddEventListener(TheDelegateType listener). I think the meaning and usage of those should be obvious enough. If the implementation wants to use events internally, it can, but I feel like that's an implementation detail that users of the interface should not care about. All they should care about is adding their listener and that all the listeners get called. Then you can just assert that HandleEvent or AddEventListener were called. This is probably the simplest way to make this more testable.
If you really need to keep the event, then see here for information on mocking delegates. My advice would be to mock a delegate, add it to the event during set up, and then assert it was called. This might also be useful if you need to test that things are added to the event.
Also, I wouldn't rely on Intellisense too much. Mocking is done via some crafty IL code, I believe. I wouldn't count on Intellisense to keep up with members of its objects, especially when you start getting beyond normal methods.
I created a class, and in that class I have a method 'sendMessage: to: withArgs:' which recieves an object, a message and an array of arguments.
The method is used to send messages to object and perform some algorithm.
To use this method I have to create an instance x of the class I created and do something like x sendMessage: '+' to: '7' withArgs: '#(5)'.
The result of this sending the message '+' to the object 7 with the parameter 5, plus some stuff that my algorithm does. But what I want is that the algorithm will be used in every method call, meaning 7+5 will call my 'sendMessage: to: withArgs:'.
How can I do that? Or at least, Is there something called in each method sent to every object?
It's kinda funny, we were just discussing that in the Squeak irc channel. Take a peek at ObjectViewer, perhaps.
In your example, you want to intercept the message sends to a SmallInteger. Funnily enough, ObjectViewer works with very much every class BUT SmallInteger.
So, to intercept message sends to myObject, do this.
Create class Intercepter, let it inherit from ObjectTracer, perhaps. Change doesNotUnderstand to something that serves you:
doesNotUnderstand: aMessage
"do Mojo to aMessage as you describe it"
Then, to get your stuff going, create your Intercepter:
myIntercepter := Intercepter on: myObject.
And then
myObject become: myInterceptor.
In Squeak, see the class ObjectTracer. The class comment describes how to use it. You should be able to accomplish what you need with that, or at least using that as a model.
Have a look at the Reflectivity.
Unfortunately some of the paper links are not working, and I don't remember the exact invocation from the top of my head, but it's really easy to instrument code as you want, and even do it at runtime. Look for examples using class Link.
You can use method wrappers. To see what method wrappers are you can look for a paper called "Wrappers to the rescue". I think there is a package for squeak that already implements method wrappers.
In addition, you can see how a test code coverage analysis is made in the last version of Pharo because it uses a kind of method wrapper to see what methods are evaluated during a test run.
cheers,
Gaboto