I think the main reason to use Perl, at least for part of this stack, is> The reason I was
> operating under the assumption that we need to use Perl for our
> testing has a number of reasons (which I write down here for others to
> challenge them):
> 1. We use Travis-CI specifically configured for Perl; I'm not sure
> which other languages are available and to what extent
> 2. With the developers we have at the moment, I'd expect to get up and
> running with a few basic scenarios most quickly in Perl
> 3. Our only option for testing seemed to be Selenium (because of
> SauceLabs), which looked "complete" at the Perl side
so we can reuse internal functions for creating test data, instead of
rewriting that functionality in another language.
However, I know we're on a path towards moving the essential business
logic to the database and providing other language bindings (and there's
already some for PHP) so that doesn't sound like a complete blocker.
> As far as using PhantomJS with Perl, this article suggests we could
> simply drive PhantomJS with the "standard" Selenium driver:
> Could it be that that driver (or the phantom-framework) provides
> enough of an API? (Actually, it looks like PhantomJS integrated the
> webdriver protocol in its 1.8 release in 2012?)
Yes, I've seen that, too -- PhantomJS can be run as a server, and
supposedly talks the same wire protocol as the Selenium driver, so
should be able to swap this out interchangeably. In either case, you
just need to start up the driver before running your tests.
> There are multiple reasons to want BDD, even though - as you point out
> correctly - it's perfectly fine for the current developers to write
> tests directly driving the Selenium or Poltergeist API.
> My reasons to want BDD are:
> 1. If we have BDD, we can solicit contributions to our testing
> framework from a much broader audience
> 2. If we have BDD, we can use that as discussion document format for
> new features to be implemented
> 3. BDD forces the creation of libraries for our testing routines. If
> you look at the t/*.t files, you'll find they get hard to follow quite
> quickly -- I'd expect the forced separation between step definitions
> and the actual steps to greatly help tests keep clean
> 4. Driving the web-tester APIs can get pretty tedious to do manually
> (error-prone); I'm thinking (hoping) that using BDD helps me gain
> developer efficiency here.
> What about my expectations (3) and (4)? Can you confirm those from
> your own experience?
I would agree with #1 - 3. Not sure about #4, though. I think it adds
yet another layer of abstraction, and complexity -- not reducing it.
After all my scouring of stuff yesterday, I think #2 is the critical
you're working on something you can't easily describe using BDD, it
raises the question "Should I really be working on this?"
> While writing the above, I've tried setting up PhantomJS testing on
> Travis CI. Actually, that worked and I've successfully connected to it
> with the selenium webdriver!
> So, we have a choice now for our testing framework to run against
> SauceLabs (real Selenium Browser-based) or against PhantomJS, it seems.
> One thing that's built into SauceLabs which I don't know how to do
> with PhantomJS is to capture images of a page at the point of test
> failure. Can you help there?
I know that's a basic functionality of PhantomJS.
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel