I'm looking to assert that I am on a particular screen during my tests, and if I'm not, then I should fail. What is the recommended way of doing this? For example, if I have a test like this:
Given that I am on the Login screen
When I press "Sign Up"
Then I should be on the Sign up screen
I've written Page Object Models for both screens involved, and they each have a trait method defined.
I've looked, and there is the TaskyPro sample (https://github.com/xamarin/mobile-samples/tree/master/TaskyPro-Calabash/features/step_definitions), which defines an "assert_screen" method. I've tried putting it into my project, but it doesn't work, as #screen is always nil. I don't have Xamarin, so I can't build their project and test it out.
You need to assign #screen first.
If your screen objects inherent from Calabash::IBase (iOS) or Calabash::ABase (Android), you could use the built in await method. You just have to set a trait or title for the screen.
A good example is the "Calabash Cross Platform Example": https://github.com/calabash/x-platform-example
In there you can see examples of how to assign screen/page objects, how to make screen/page objects and how to check if a screen is visible.
We use screen objects all over our tests, and they help a lot when you need to use the same tests on multiple platforms.
I would recommend that you also use the transition method on the screen/page objects to navigate between screens.
Related
Our Application has components which consume components with consume components of varying complexity. So i just want the input on the page, to validate when an object is set that the text is correct. The issue is that it is one of these subcomponents.
My colleague told me that there is 2 ways to do this, The first is to use Page Objects, and Chaining annotation to find it on my page, and then find the next id etc until my input is found. It requires me to look through another teams' Component Markup to narrow it down to the input i want to leverage. I dont believe I should have to go into another component definition, or a definition of a definition to get the appropriate chain to get this arbitrary input. It starts to create issues where if a lateral team creates changes unbeknownst to me, my PO will be broken.
The other option my friend asked was to use fixture.query to find the component. This would be as simple as:
fixture.query((el)=> el.attribute["id"] == "description",
(comp){
expect(comp.value, value);
});`
Using Query looks at the markup but then will automatically componentize it as the appropriate SubComponent. In this case, comp.value is the value stored in the HTML. So, if i did something like:
fixture.update((MainComponent comp) {
comp.myinput.value = new Foo();
});
Then I am setting and getting this programmatically, so i am a bit unsure if it properly would reflect what is on the screen.
Whats the best course of action? It seems PO would be better, but im not sure if there is a way around having to deep query for input boxes outside of the component i am testing.
Thanks
I don't think I have a definitive answer for you but I can tell you how we do it at Google. For pretty much any component we provide the page object alongside the component. This is twofold it is for testing that widget, and also so we can have this as a shareable resource for other tests.
For leaf widgets the page objects are a little less fleshed out and are really just there for the local test. For components that are shared heavily the page object is a bit more flushed out for reusability. Without this much of the API for the widget (html, css, etc) we would need to consider public and changes to them would be very hard (person responsible for making the public breaking change needs to fix all associated code.) With it we can have a contract to only support the page object API and html structure changes are not considered breaking changes. At times we have even gone so far as to have two page objects for a widget. One for the local test, and one to share. Sometimes the API you want to expose for a local test is much more than you want people to use themselves.
We can then compose these page objects into higher level page objects that represent the widget. Good page objects support a higher level of abstraction for that widget. For example a calendar widget would let you go to the next/previous month, get the current selected date, etc. rather than directly exposing the buttons/inputs that accomplish those actions.
We plan to expose these page objects for angular_components eventually, but we are currently working on how to expose these. Our internal package structure is different than what we have externally. We have many packages per individual widget (page_objects, examples, widget itself) and we need to reconcile this externally before we expose them.
Here is an example:
import 'package:pageloader/objects.dart';
import 'material_button_po.dart';
/// Webdriver page object for `material-yes-no-buttons` component.
#EnsureTag('material-yes-no-buttons')
class MaterialYesNoButtonsPO {
#ByClass('btn-yes')
#optional
MaterialButtonPO yesButton;
#ByClass('btn-no')
#optional
MaterialButtonPO noButton;
}
I am making a new graphical menu interface for a project I am making. I don't want to use the menu system provided by windows APIs and want to make one from scratch.
My question is, what is the best method for setting up the structure?
I'm thinking I will need a menu item object, each of which will have to have their own item array list, etc...
Is it considered sloppy to have recursive coding like that? (Ie an object which contains objects of itself, which contains objects of itself, etc...)
I'm thinking I can give the item object a draw interface which checks itself to see if it has an item array that is not null. If it does, it executes the draw command all the way down, thereby giving me a menu with (for my purposes) unlimited submenu level
In my opinion your approach is fine. In nearly all UI frameworks, views contain views as subviews after all.
But the thing is that writing drawing code is too much work for small projects I think. I would consider using a UI framework such as QT and use its view mechanism as a starting point. You can write your own Menu class which will be a subclass of generic View class in the framework.
I am trying to learn Coldbox to perhaps replace the current framework I am using. One of the features that I currently use is the ability to override any of the template inclusions by convention.
Essentially, lets say I have a view, "views/home.cfm"
<h1>I am the default theme</h1>
and that is all well and good. But lets say that I have a different view, "themes/[theme-name]/views/home.cfm"
<h1>I am the user chosen theme</h1>
that I want to include conditionally (say there is a cookie to determine what theme is in use). Also, if the file does not exist, the default/fallback view should be rendered.
Is there any way of doing this overriding the system functions?
I looked at interceptors, and the preViewRender and postViewRender interceptors seem like the place to do something like this, but there doesn't seem to be any way of manipulating the actual workflow. If seems to be mainly pre/post processing of the content. For instance, there doesn't seem to be a way to "return false" to tell the renderView method to not actually render the view. Or any way to affect the location in which the view is to be found.
Any ideas?
Tyler,
The ColdBox Framework is quite flexible. It is possible to do what you desire but I don't think modifying renderView() is the best way to resolve this--although, you most definitely can.
I would encourage you to create a User Defined Function in the /includes/helpers/ApplicationHelper.cfm file that contains the logic you require. The functions that are added to this helper file are accessible from anywhere in the framework. This would allow you to create a function called "renderSkin()" that contains the logic you need. RenderSkin() would ultimitly call "renderView()" when you finally figured out which template you wanted to render for that user.
Respectfully,
Aaron Greenlee
I would suggest you go with the interceptor route, but change the layout instead of the view.
From the postEvent interceptor you can get the processedEvent key from the interceptData to change the layout.
Otherwise you could just make the check part of the layout page. The layout can the be a switch statement (or a more OO approach) $including the themed layout files as needed. This has the advantage of giving you a chance to emit custom interception points and having common functionality (css, js)
I have been away from C++ for a couple of years now doing AS3/Flex work. I have gotten used to being able to create a component and place it in design mode with very little fuss and I am struggling to get my head around the C++ Builder way of doing the same thing.
I have written many components for C++ Builder in the past, but none of them have been visual. What I would like to do now is create a component for customer search and another for order processing because I want to be able to create a new instance of these on the fly. What I don't want to do is have to place each of the components like the dbgrid and search fields manually in code. I would like to do this (as well as set their properties) in design mode.
How do I go about this? I have browsed the source for other Delphi components and I notice they have dfm files which seems to be what I need. How do I do this in C++ Builder? The only option I see is to add a new form if I want a dfm, but this isn't what I want as my components will be based on TPanel.
Is there a way to do this or do I have to resort to doing it all in code with no visual reference?
Pursuing the DFM idea I did a test this morning where I created a component based on TPanel and added a new form to it which I create and parent in the constructor of the component. In design mode I set the form border to none and placed a grid on it. This all looks OK until I place the component in my application, at that point it looks like a panel with a standard looking form in it and the grid is missing. If I run the app the panel shows as expected, borderless and with a grid. The DFM appears to be ignored in design mode for some reason.
If you know a better way to do this than using components then please give me some pointers.
Any help and advice will be appreciated beyond words
You might want to have a look at frames (look for "Frame objects"). They are "subforms" you can design visually and then place on forms.
Just as an FYI item, you can also drop the panel on a form, put any other controls on it, position them, set captions, etc..
Now, click the panel to select it, and use Component->Create Component Template from the IDE's main menu. This creates a unit you can install as a component which will add the panel and it's sub-controls (as a single component) to the IDE's component palette.
Of course, you can then modify the source for that new component like any other component source.
Wanting to check if I missed a setting somewhere, or if I'm just using the product in an unintended fashion.
I've created a prototype based on an existing site, and am using states to mimic functionality, along with tabcontrols and the like. When the end-user is marking up the page, and then changes tabs, or clicks a button to change states (but stay on the same 'screen'), the drawings from the end-user remain in the same spot. The issue is that if the user highlighted or crossed something out, it interferes with the new state.
Is this intended, an undocumented feature, or am I just expecting a little too much? This may be a dealbreaker for us using this tool in our organization if we can't either resolve or have a reasonable workaround. I'm open for suggestions.
I believe feedback is stored at the 'screen' level not the 'state' level
I suppose you have 3 choices:
Instruct your users to list the steps they did before they add their feedback
Change your states to different screens instead (they can still look like the same screen for the end user, but in your application they will be different screens)
Have your user submit screen shots instead of just .feedback files
The second option will allow you to organize your feedback better.
In short I think you're expecting more than they offer ;)