HtmlToText
fred beringer software development, software testing, productivity and … life ! home about fred beringer home about software development, software testing, productivity and … life ! appium is not ready for prime time (part 2) december 10, 2013 10 replies i decided to write a second part to my “ 4 reasons why appium is not ready for prime time ” article. there was an interesting comment posted by satyajit malugu which i thought required a post by itself because it raises some important questions. hopefully, some additional comments will keep coming as i’d like to inform as much as possible testers and developers about the current state of appium. here are the 4 comments made by satyajit 1. no implicit waits – appium has good support for implicit waits. ruby_lib is using them and my tests rarely have to wait on something. let me know i can provide my logs of this works. i’m not a big fan of implicit waits as they don’t offer flexibility for specific elements you want to wait on. you basically define a global wait-for-element for the entire duration of the test. typically i woud want to use different type of waits wether i’m dealing with screen-flow for my app or if i need to wait for the return of a back-end call. implicit waits don’t give me this flexibility. additionally, i can’t specify the element i want to wait on. finally, i didn’t see any capabilities to wait for other element’s charactertics such as count, color, enable/disable, etc. explicit waits are much more powerful and flexible. that’s why we spent a lot of time implementing them in our product and we add new ones almost every week based on the feedback we receive from our community. 2. no parallel runs – appium/sauce labs philosophy is to use emulators in their cloud and the support parallel tests, its in their road map but not there yet i have 2 problems with this comment: i can’t recommend an open source mobile test automation that rely on a commercial vendor to run tests. i like sauce labs, i like what they’ve done for web browser testing but if i want to use an open source solution, i want the benefit of open-source all the way. so if i’m not using saucelabs, i’m left with buying 500 mac mini if i want to run 500 ios tests in parallel. not too sure this is a good investment. sauce labs executes tests on simulators. so if my tests pass on a simulator, am i good to go? can i ignore testing on real-device? of course not and i still don’t know why testers still run their regression tests on simulator. i understand why developers use them: it’s cheap, it’s integrated within their ide, it’s great to debug their apps. but testers? let’s get serious. simulators are not the right platform to run tests in my opinion: way too many false-positive (and negative!), they come with stock os which is a problem on android where there are plenty of oem customizations, network connectivity comes from the client (pc or mac) and is very different from what you get on a real devices and finally the cpu/memory they simulate is not fit to run any serious performance testing. 3. gestures – there is support for gestures, not in the most easiest of the ways but i am able to flick, swipe, long tap etc. now tell me which other framework provides you even that? mobile apps rely heavily on gestures and support for all of them in a mobile test automation product is critical. it shouldn’t require any coding and should be easy to use. appium is not there yet and somehow i find it perfectly normal. i’ve seen the soasta engineering team working endless hours to support all of them across native, hybrid and mobile web apps on both ios and android. it’s a lot of work but this is the price to pay to offer ease of use and full support to testers and developers on all platforms. we today support 60+ standard gestures on both ios and android, so yes it is possible. 4. limited support for android < 4.1. now is it appium’s fault that google decided to come up with new framework 17+? also there are couple of projects underway to merge selendroid into appium, or using espresso. if you are motivated enough, you could create implement a page object design pattern and use selendroid and appium in the same test suite. when you build an automation framework, you look at your market and you’re trying to support the majority of your users. today, appium supports 18.2% of the market. if i’m a developer or a tester, is this sufficient? can i wait for appium to come up with support for < android 4.1? or should they not start their automation project until carriers and manufacturers decide to upgrade the phones of their users? should they mess with selendroid and read pages of support forums to make their solution work for android < 4.1? appium decided to invest in the future and that’s fine. but it means that testers will use the solution … in the future. keep the comments coming! state of testing survey 2013 december 6, 2013 1 reply there is a cool initiative going on from the folks at tea time with testers and qa intelligence . they’re launching a survey to help us understand the state of testing! what are the main challenges in the profession? where is the profession headed? i’m definitely supporting the initiative and interested in the results! i’m following the software testing trends via analysts but a survey coming from the community could be quite insightful! you can take the survey here. note: i have no affiliation with the survey. 4 reasons why appium is not ready for prime time december 5, 2013 6 replies as someone responsible for a mobile automation product, i spend a reasonable amount of time looking at the competition. i particularly like when i see some innovation, something that forces us to do even better and stay ahead of everyone else. usually, this innovation comes from small company or from the open source community. appium has been on my radar ever since it came out, but i waited for appium to get some maturity before trying it out. my conclusion is very simple: appium is not ready for prime time. it reminds me of selenium and webdriver in its infancy. not something you want to invest in for serious work. maybe fine for individual developers to build some smoke tests, but if you have an enterprise app for example, with complex gestures and a lot of tests to build and maintain, appium is not a good candidate, yet. these are the main shortcomings i’ve noted. some are really showstoppers for me. #1 – no support for intelligent waits. this is the biggest shortcoming and a big red flag. you can code some time delays (polling loops) and that’s it. a time delay is the worst mechanism to manage your page flow or address back-end response time variability. reasons being: how long should i wait after a back-end call? yeah, let’s put 10 seconds, it should be way enough. it might work for 90% of the time and you end up spending time investigating errors for 10% of your test cases. the goal of automation is to find regression issues in your app! not problems with your environment. how long should i wait to account for device performance? transition between pages depends a lot on the performance of your device. might be almost instantaneous on the latest ipad air for example with their new cpu and could be crawling on older ios devices. so should you add 2 secs each time you transition between screens in your app? should be enough right? sure, it should be fine. multiply these 2 seconds by your number of transitions, number of tests, number of devices and you end up with a lot of hours spent waiting! when you have 10000 tests to run during the night for example, that’s not something you can afford. especially when developers need feedback fast! without being able to wait on a ui element characteristics (visibility, value, etc.) to manage page flow or back-end call, an automation framework for mobile is pretty much worthless in my book. #2 – on ios, you can only execute one test at a time per mac. this is a limitation com
Informations Whois
Whois est un protocole qui permet d'accéder aux informations d'enregistrement.Vous pouvez atteindre quand le site Web a été enregistré, quand il va expirer, quelles sont les coordonnées du site avec les informations suivantes. En un mot, il comprend ces informations;
Domain Name: FREDBERINGER.COM
Registry Domain ID: 1533101441_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.ovh.com
Registrar URL: http://www.ovh.com
Updated Date: 2016-10-21T00:12:15Z
Creation Date: 2008-12-15T16:00:32Z
Registry Expiry Date: 2017-12-15T16:00:32Z
Registrar: OVH
Registrar IANA ID: 433
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: DNS13.OVH.NET
Name Server: NS13.OVH.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2017-09-05T09:58:22Z <<<
For more information on Whois status codes, please visit https://icann.org/epp
NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.
TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.
The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
REGISTRAR OVH
SERVERS
SERVER com.whois-servers.net
ARGS domain =fredberinger.com
PORT 43
TYPE domain
RegrInfo
DOMAIN
NAME fredberinger.com
CHANGED 2016-10-21
CREATED 2008-12-15
STATUS
clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
clientTransferProhibited https://icann.org/epp#clientTransferProhibited
NSERVER
DNS13.OVH.NET 213.251.188.132
NS13.OVH.NET 213.251.128.132
REGISTERED yes
Go to top
fredberinger.com rapport :
Visitez le site