I am writing a test that fails with following error:
Error Domain=com.google.earlgrey.ElementInteractionErrorDomain Code=0 "No element found." UserInfo={NSLocalizedDescription=No element found.}
I can see in the generated screenshot that the element I am trying to match exists. I stepped through the code and saw that earlgrey uses element providers. When my test failed, I saw a ui hierarchy dump. I want to print the exact same ui hierarchy at specific breakpoints instead. How can I do that?
You can use the GREYElementHierarchy class to print the element hierarchy at any point in your EarlGrey test.
UIWindow *hierarchy = [[[UIApplication sharedApplication] delegate] window]);
NSLog(#"Hierarchy: %#", hierarchy);
As in EarlGrey FAQ you can add a breakpoint anywhere in your tests and, when hit, run in Xcode's debug window:
expression -- print(GREYElementHierarchy.hierarchyStringForAllUIWindows())
This will output the complete hierarchy so it will be a little confusing to parse out.
Good luck
Related
I'm using Dexie.js version 3.0.3-rc.3 in a Vue JS project and I occasionally run into this exception in Chrome (86):
Failed to execute 'bound' on 'IDBKeyRange': The parameter is not a valid key.↵ DataError: Failed to execute 'bound' on 'IDBKeyRange': The parameter is not a valid key.
Here's a screenshot of the full error:
I'm fairly certain the problem lies with something in my data being undefined, but I'm trying to find a good way to troubleshoot this. I paused the Chrome dev tools on exceptions and inspected the code around this particular part of Dexie, but it doesn't reveal what data was used to make this exception occur.
Does anyone have any suggestions on how to find out what's actually wrong? It feels a bit like a needle in a haystack.
== Update ==
Below is the full call stack:
Try inspecting the call stack. I know it can be long until you reach a frame within your application code, but the failing call should be there!
I'm unable to understand how the mock-debugger extension controls where the next step is.
For example what if I'd like to step 2 lines if I find the word "banana" in my text? Also, I'd like to do something, like "Step In", where I can walk word-by-word - is it possible?
I've seen the this._currentLine = ln; assign, which looks like it controls where the line is, but it's just a simple local variable. How could it ever control anything in the debugger? I can't find any other uses of the _currentLine varbiable where it passes to anything useful API (except for stack tracing, but I don't think it has any relation with the debugger line-control).
The stack trace is the only source for the debugger step visualization. When the debugger gets a notification to pause it requests the current stack trace. The TOS determines where the next execution point will be located. Hence the debug adapter is reponsible to determine this position precisely.
I want to perform click and scroll down action on a element .
* Already i tried with Action class
* javascript executor.
* Robot class
First I am trying to click on element and hold it for a while and then scroll till expected element finds but I am getting error as method has not yet been implemented.
WebDriverException: Method has not yet been implemented (WARNING: The server did not provide any stacktrace information)
1.The above error comes when your app is not matching with the current context
2.According to your code there is a need of context change of app environment you can change context using driver.context("YOUR APP CONTEXT NAME")
3.Some times there must be error in your code like it is not locating correct element or may be you are using unwanted method
Try above 2 points it might help you
if it is not working sorry for wasting your Testing time
Happy Testing
I have a UIbutton in my app. When I click the button, it removes the last object in a NSMutableArray. For this, I want to write unit tests.Please any one give me your suggestion.
I use this code for knowing when a click on the UIButton was performed:
[viewControllerObject.backButton1 sendActionsForControlEvents:UIControlEventTouchUpInside];
Thanks,
Ricky.
At a "unit" level there are two things you're testing:
does tapping the button send the action method?
does the action method remove the last object from an array?
Ignore the first one, that's Apple's problem (or charitably it's an integration test). The second is straightforward if you think about the Assemble, Act, Assert process:
Assemble: build your view controller and its content array.
Act: call the action method.
Assert: check that the last object was removed.
-(void)testRemovalOfLastObjectOnButtonAction
{
//... build and populate the view controller
id lastObject = [array lastObject];
[viewController buttonTapped: sender];
STAssertFalse([array containsObject: lastObject], #"Object %# should be removed", lastObject);
}
Note I test explicitly whether the last object was removed, not whether the count was decremented: that could happen if any object were removed.
You can do this in several different ways. A suggestion would be to watch this great tutorial
The video explains how to unit test in UIKit.
XCode has native support for Unit Tests. If you start a new project, look for the check mark that says 'Include Unit Test'. If you use that, you will have a folder called <project_name>Tests. Open the .m file in there, and you'll see a - (void)testExample method where you can put your tests.
You can use a number of functions to test, like STAssertTrue and STAssertNotNil. Check out the Apple docs here: https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/UnitTesting/03-Writing_Test_Case_Methods/writing_tests.html#//apple_ref/doc/uid/TP40002143-CH4-SW1
In your case, you could probably do something like this:
NSInteger arrayCount = mArray.count;
[yourInstance performButtonAction];
STAssertEquals(arrayCount -1, mArray.count);
For assert macros in my iPhone project, I'm looking for a way to programmatically break into the debugger. On Windows (MSVC++), I can use __debugbreak() for this purpose. Invoking this function will stop my program, launch the debugger, and display a callstack of the line that called __debugbreak().
Is there anything similar to __debugbreak() for the iPhone? I've tried Debugger(), but that gives me a linker error.
Thanks,
Claus
edit
Turns out this also works:
#define Debugger() { raise( SIGINT ) ; }
I think it's the same principle.
I use this:
#define Debugger() { kill( getpid(), SIGINT ) ; }
I think it works
in the simulator and on the device.. no assembly required!
A helpful person on Apple's developer forum gave me the tip to use asm("trap") when running on the device and asm("int3") when running on the simulator. This makes the program break into the debugger if you started your programm in debug mode (Option-Command-Y).
(__builtin_trap() also breaks into the debugger, but you can't continue afterwards. assert(false) terminates the program with a message, but doesn't break into the debugger.)
First Add -DDEBUG to OTHER_CFLAGS on your debug target; this will define the DEBUG symbol when building a debug build.
Then add a simple assert macro to your prefix header:
#ifdef DEBUG
#define MyAssert(val) _MyAssert(val)
#else
#define MyAssert(val) do { } while(0)
#endif
Next create a _MyAssert function in a module somewhere:
#ifdef DEBUG
void _MyAssert(int expression)
{
if (expression == 0) {
NSLog(#"Assertion failed!"); // Place breakpoint here
}
}
#endif
Finally create a breakpoint on the NSLog line.
I just set a breakpoint at the place I want to stop. Xcode remembers breakpoints persistently, so any time I run the app with gdb, it'll stop at that point.
If you want to break on assertion failures, a good place to set a breakpoint is on the function objc_exception_throw, in the Objective-C runtime, which is what actually throws an exception. Use the Run > Show > Breakpoints window and double-click the "Double-click for symbol" row, then type the name.
Is there something wrong with the simple assert() macro? Something like
assert(pointerToTest != nil);
will halt your process at that point if the condition is not true. If running under the debugger, you'll be presented with a stack trace of calls that led to the failed assertion. If you want to trigger it every time you hit a certain code path, you could do
assert(false);
I find these assertions extremely useful for verifying that all IBOutlets are non-nil when a window or view is brought up from a NIB.
If you run your program in debug, your app should launch the debugger when it reaches an invalid assertion.
For it to stop, as Jens Alfke tried to say, you need to enable "Stop on Objective-C Exceptions" (under the Run menu).
For more info about debugging vs. releasing and asserts, read http://myok12.wordpress.com/2010/10/10/to-use-or-not-to-use-assertions/
While an ancient thread, found this while researching same topic for Xcode 7. What solved this for me was a feature called "Create Exception Breakpoint..."
Debug > Breakpoints > Create Exception Breakpoint...
This puts a special breakpoint in the Breakpoint Navigator (under View > Navigators > Show Breakpoint Navigator).
This breaks on the actual throw of the exception:
[ exception raise ]
without terminating your code execution. You can just continue if that is how your code is structured.
Double-clicking the break point marker next to "All Exception" lets you adjust where and how the exception break point stops:
Check out conditional breakpoints:
http://www.cocoabuilder.com/archive/message/xcode/2008/10/22/25358