When testing using the POM model data pattern, is it best to have the locators for elements in the page object or have them in a separate file like the test data
pageObject
loginPage
homePage
testDate
loginPageData
homePageData
pageLocators
loginPageLocators
homePageLocators
specs
loginTest.js
Many thanks
Everything is good what is good FOR YOU. There is no single right answer. So I'll share my experience utilizing POM in my current project.
No one ever thought of one minor downside of POM: navigation down the chain to get to the bottom locators.
I worked for a while with perfectionists who believed if something is logically different, it should go into a separate file. Thus, we had locators stored separately from elementFinders and methods that interact with pages. This was reasonable, but consider what I need to go through if I debug a failed test:
to find a failed line in a spec and jump in the source code of the method that causes error
This method belongs to extended class and depends on parental class, so I jump in the source of the class
That method interacts with an element, defined somewhere else, so I have to open that file
the element has locator stored in another file, so I need to find that file too
Finally, when I found my locator, I forgot what I was doing, not to mention tediousness of the process and waste of time.
Therefore in my next project, I tried to balance this neatness of the code with overall usability and easiness of navigation between files, and was happy with the way I structured the code
Good luck!
Related
I'm trying to see whether it's possible to use the code from DuckDuckHack Instant Answers outside of the context of the main DuckDuckGo website. After all, an Instant Answer is mostly a standalone component that consists of some HTML, CSS and Javascript and should be relatively self-contained and reusable.
Since the DuckDuckHack project is in maintenance mode, it seems to be a bit difficult to obtain information: the Slack and Forum mentioned on the Developer Guide have been disabled. I tried to find out whether other people tried to make Instant Answers work in other contexts, but I couldn't find anything. There are tutorials on writing Instant Answers, such as this using Perl and the DuckPAN tools. I tried to get an existing Instant Answer to work using those tools but I failed to get it to work properly (not sure whether they are still maintained).
Since those tools seem to be a bit heavyweight, I thought it could be possible to bypass them completely and try to just use the HTML, CSS and JS from the Instant Answer directly.
I've given the Calculator a first shot. I identified the relevant source code in the duckduckgo/zeroclickinfo-goodies repository's directory share/goodie/calculator. The HTML seems to be in the content.handlebars, and then there's calculator.css and calculator.js. I created a plain HTML file, put the HTML from content.handlebars in there and included references to the CSS file and the JS file. At first, the CSS wouldn't work because the CSS rules don't apply without adding some more wrapper divs that can be easily found when inspecting the DuckDuckGo site with the calculator Instant Answer visible. After adding those wrapper divs, the calculator UI appears more or less intact. However the buttons of the UI do not work at all yet.
Looking at the Javascript console I get this error:
Uncaught ReferenceError: DDH is not defined
at calculator.js:1
Apparently an object DDH is required by calculator.js, however I have no idea what that object should be and how I could create it.
Does anybody know how this DDH variable gets usually initialized or more generally how to make this work? Any reference to projects reusing the code from DuckDuckHack for their own sites would also be highly appreciated.
I think the details of how the DDH object is put together might not be exposed through the open-source portion of DDG.
I've also made some attempts to repurpose some of the built-in DDG IA functionality (e.g. get programmatic access to the many, useful instant answers unavailable through their API).
In the process, I cloned the goodie repo and poked around. The pattern seems to be that for most goodies the payload to be displayed is DDH.<goodie>.content. In my local copy of the goodie repo:
$ grep -rE 'DDH' ./lib/
./lib/DDG/Goodie/Conversions.pm: content => 'DDH.conversions.content'
./lib/DDG/Goodie/Conversions.pm: content => 'DDH.conversions.content'
./lib/DDG/Goodie/Game2048.pm: content => 'DDH.game2048.content'
./lib/DDG/Goodie/PublicDNS.pm: list_content => 'DDH.public_dns.content',
./lib/DDG/Goodie/JsBeautifier.pm: content => 'DDH.js_beautifier.content'
./lib/DDG/Goodie/SassToCss.pm: content => 'DDH.sass_to_css.content'
./lib/DDG/Goodie/Constants.pm: title_content => 'DDH.constants.title_content'
...
On the javascript side of things, you'd find the corresponding .js files in the share/goodie directory, as you did for the calculator goodie.
The <goodie>.js files seem to introduce DDH.<goodie> namespaces (typically right at the top of the file) and define DDH.<goodie>.build functions. This procedure is referenced in the goodie-display docs (see the section titled Setting Goodie Display Options on the Front end therein).
Nowhere in the docs, though, is it documented how the content property of DDH.<goodie> is put together. I cloned the docs repo and grepped for DDH, revealing nothing to that effect.
None of the .js files in the share/goodie folder of the goodie repo, though, seem to give a clue as to how DDH.<goodie>.content is assembled either. Indeed, some of those .js files do not even contain the string content. For a listing of all share*.js files that do contain the string content, I did (in the local copy of the goodie repo):
$ find ./share -name "*.js" |xargs grep -l 'content'
./share/goodie/countdown/countdown.js
./share/goodie/text_converter/text_converter.js
The other .js files do not contain that string at all..
Edit
On the other hand though, I see you did manage to get the calculator going with some modifications to the .js file (e.g. by inserting that missing DDH namespace).
For the first time as a jnr progammer I'm looking at how to write my js code so that it's isolated to certain pages within my Rails app. I figure this is a sensible thing to do for the purposes of;
a) certain js i write I only want to target a certain element on an individual page, not other elements on other pages within the same controller that may get picked up due to using a class selector for example and marking every single thing with unique id's doesn't seem too neat. (I see that rails already has controller isolation through the naming of js files by controller, but further dividing things up into action/page names js files doesn't sound nice either!).
b) perhaps in finding a solution to only running js on certain pages it could mean that the js only needs to be loaded on certain actions thereby saving on load times.
There's a well attended question here with folks approaches here but most answers are 6 years old now and another nice post about the so called 'Garber Irish method of Dom ready execution' here that sounds quite nice, but again this is quite old now and all based on Rails 3...
So without wanting to create duplicate content I'm seeking to get a refreshed answer to this same question and find out whether there's a best practice now established these days.
Thanks
Convention:
Rails when using scaffold generator by default creates corresponding
app/assets/javascripts/MODEL_NAME.coffee
app/assets/stylesheets/MODEL_NAME.scss
which separates JS and CSS logic by "controller" name
Personal Preference:
Rather than controller-based segregation, I prefer layout-component-based segregation. Best explained through a sample code below:
app/assets/javascripts/application.js
//= require_tree ./layouts/
app/assets/javascripts/layouts/__shared.coffee
// WRITE GLOBAL JS LOGIC HERE FOR ANY LAYOUT
app/assets/javascripts/layouts/application/__shared.coffee
// WRITE GLOBAL JS LOGIC HERE ONLY FOR THIS "application" LAYOUT
app/assets/javascripts/layouts/blog/__shared.coffee
// WRITE GLOBAL JS LOGIC HERE ONLY FOR THIS "blog" LAYOUT IF YOU HAVE ANOTHER layout such as "layouts/blog.html.erb"
app/assets/javascripts/layouts/application/components/header.coffee
// WRITE JS code here for the header component
app/assets/javascripts/layouts/application/components/footer.coffee
// WRITE JS code here for the footer component
app/assets/javascripts/layouts/application/components/users/__shared.coffee
// You can also divide a component into subcomponents just like this
// WRITE JS code shared amongst all users subcomponents
app/assets/javascripts/layouts/application/components/users/form.coffee
// WRITE JS CODE HERE regarding the form that creates or updates a User
app/assets/javascripts/layouts/application/components/users/list.coffee
// WRITE JS CODE HERE regarding the table listing all users
You also structure the CSS files in the same way, matching the components
I would like to ask your advice on our situation about dynamic/static loading components.
We're developing a "multi language teaching app" for Android/iOS. For UI text we use ng2-translate plugin (JSON files for each language). For the lesson content we use separate HTML files for each language. In the beginning the user selects a language to learn and then sees related lessons as a list (which comes from a JSON file too). Clicking a lesson loads the related HTML file and dynamically compiles directives/pipes in it (which makes it more interactive). By directives, I mean simple functions like showing a toast when user clicks a custom directive, like this: <example tooltip="explanation to show as a toast">An example sentence</example>. But maybe we can use more complex directives in the future.
Up to building the app, everything goes well in browser. But the AoT compiler does not support "dynamic loader components" in mobile devices, so we need to decide whether or not use this approach. And at that point I'm really confused. We may change our structure but I don't know which way is better.
As far as I can see, we have three options (if there are more, please enlighten me):
Stop using html files and convert each of them into a component with html templates (using AoT compiler (--prod mode)):
Be able to use directives/pipes
Gain interactivity
Gain performance (that's the main purpose of AoT, right? but what if I use hundreds of html pages/components? isn't it a bulky solution?)
Use hundreds of pre-compiled html pages for grammar lessons, stories, texts...
Load pure HTML files into an innerHTML of a loader component (using AoT compiler (--prod mode)):
Don't use directives/pipes
Loose interactivity (except being able to use simple HTML tags like p, strong, em, table etc. --if we count this as an interactive content)
Gain performance a bit (as we use AoT?)
Load HTML files dynamically as components via one dynamic template component (using JiT compiler (--dev mode)):
Be able to use directives/pipes
Use separate html files
Gain interactivity
Loose performance
Do something that Angular generally does not recommend
I can't decide what to do now, if I want more interactivity, I should drop the performance that Angular proposes.
I just wanted to be able to handle these grammar lessons in a simple syntax (like HTML) as seperate files and not to use/declare components for each of them...
What would you recommend?
I asked same question to Ionic forum and I decided to implement the solution of a user that replied to me:
I went through this with Markdown, tried a bunch of things, and here's what I eventually settled on:
Store your objects however is convenient for you. In my case, that's markdown source.
Define two components; we'll call them skeleton and bone for now.
skeleton has an input property giving it the source. In ngOnChanges, you need to parse that source into an array of elements, each corresponding to a different type of bone.
skeleton's template looks something like this:
<template ngFor let-bone [ngForOf]="bones">
<app-bone [bone]="bone"></app-bone>
</template>
Make sure each bone has a discriminator indicating its type, and then the BoneComponent template is a big giant switch:
<blockquote *ngIf="bone.tag === 'blockquote'">
<app-bone *ngFor="let child of bone.children" [bone]="child"></app-bone>
</blockquote>
<br *ngIf="bone.tag === 'br'">
... every other block-level element we support...
Note that this can work recursively if you need it to, in that the
inside of the blockquote case is effectively another skeleton. I'm
using HTML elements here, but the general technique works equally well
for other user-defined components (as types of bones).
I have two conceptual parts of the site - public, which is shown to users when they are guests.
I want public part to be as lightweight in the JS code as possible, rendering many elements on the server and passing them as HTML, then doing some stuff with client JS code.
The user part of the site is when user logs in and it's more dynamic in its structure, can be quite large in its JS code size. User manages her content here, add, remove, search and filter. It's fine to wait some more time while this part is loading.
I suppose, I want to make codebase separate for public and private parts of the site but I still want to not duplicate code if possible, between two.
I see these ways:
1. Use a small JS file which figures out where it's located and then loads the main logic file depending on the current context - private or public.
2. Completely separate logic and put into 2 independent files, then attach to 2 respective html templates.
3. Have a file with logic for public part, and if it happens that user logs in, dynamically load private logic file from the public file.
How do I decide what way is the best one? Please advise.
I believe your 3rd approach would work the best.
1st brings latency coming from intermediate step for determining user current privileges. 2nd require full page reload. 3rd seems most reasonable if done right.
If you set a cookie to remember that user is logged in for the next visit you could possibly attach both scripts on server (if your HTML is generated dynamically) or even have them merged together for sending as one file when needed. If using some build tools like gulp or grunt this could be easy to maintain.
I use require.js to do lazy loading for a Javascript app. I would love to switch to a meteor stack but right now it looks like Meteor sends the whole app (all the templates) through on the initial load. Has anyone had success with require.js and meteor or any other implementation?
You're asking different questions, but certainly they are connected. The first is about loading additional javascript code into your meteor app. Of course you can use thing like requirejs. This should work fine supposing your lazy code is located in the public directory of your meteor project. However, my experience is that requirejs goes mad when the contents of public gets updated often, so for example in the development environment. Maybe it's a matter of customizing the library, but I would rather recommend using some lightweight homebrewed package. Look here, if you need some inspiration.
The second question is about lazy template definition. Each template consists of two parts. The first is its html code, written in handlebars syntax, the second is all the javascript code which you write to define how your template should behave (e.g. helpers, event handlers). The second part is easy, as long as we assume that we already know how to load the lazy code (see the above paragraph) and the template, lets call it myLazyTemplate, is already defined, so basically speaking Template.myLazyTemplate is not undefined. So how to achieve the latter?
To dynamically define a new template you'll need to call
Template.__define__(name, raw_func)
on the client. So the last question is "what is raw_func?". This is a compiled version of your html code which is normally created automatically on the server and then sent down the wire to the client when the app gets loaded (look here to see how it's done in meteor). But we want to do it dynamically, right?
So the idea is to compile the template code manually with a help of the Handlebars.to_json_ast routine. You can feed it with your template html code, and the output is some javascript array that can be sent to the client anytime by the method we've already talked about. The last thing you need to do is to call Handlebars.json_ast_to_func on the client, using the data sent from the server as the only argument. The output produced by Handlebars.json_ast_to_func is the raw_func you can use to produce myLazyTemplate template.
I'm aware that this is only a rough idea, not the whole solution to your problem. I hope this will help you to figure out the final solution on your own.