Posts Tagged ‘Selenium’
[DevoxxUK2026] Aspiring Speakers: Learning Python to Buy Shoes
Lecturer
Isaac Oldwood is an emerging software engineer and public speaker passionate about accessible, project-based learning. His journey from mathematics student to developer exemplifies practical skill acquisition through real-world problem-solving.
Abstract
Isaac Oldwood shares a personal narrative of mastering Python by tackling an everyday challenge: automating the purchase of limited-edition sneakers. This beginner-friendly account traces the evolution from rudimentary automation scripts to sophisticated API interactions, highlighting key lessons on learning through failure, iteration, and building relevant projects.
From MATLAB to Real-World Automation: A Developer’s Origin Story
Beginning in 2016 as a first-year mathematics student at the University of Nottingham, Isaac encountered programming through a compulsory MATLAB module. Recognizing the value of coding skills for modern mathematicians, he excelled yet questioned his academic path upon receiving strong results. Seeking guidance through traditional searches, he discovered that foundational knowledge in variables and control structures should pair with building practical projects aligned with personal interests.
The chosen project involved acquiring Yeezy Boost 350 V2 “Bred” sneakers. Initial attempts employed PyAutoGUI for keyboard and mouse automation, relying on screen coordinates and arbitrary sleep timers. These approaches proved brittle against dynamic web interfaces and competitive release timings.
Subsequent iterations leveraged Selenium for browser automation, enabling direct interaction with HTML elements and conditional waits. This advancement improved reliability as scripts adapted to page changes. Further research into inter-computer communication revealed APIs, leading to direct HTTP interactions using the Requests library. By reverse-engineering checkout flows, Isaac implemented PUT requests to cart endpoints and POST requests for payment processing, dramatically reducing latency compared to full page loads burdened by images, trackers, and fonts.
Scalability challenges emerged when extending the solution to housemates. Synchronous execution created unfair queuing. Transitioning to asynchronous operations with HTTPX allowed concurrent checkouts, ensuring equitable opportunity at release moments.
Despite technical refinements, the script ultimately failed against robust anti-bot measures deployed by the retailer. Success arrived through manual effort: queuing physically outside a store at dawn. This outcome reinforced that automation serves as a learning vehicle rather than a guaranteed solution.
Conclusion
Isaac’s engaging story underscores fundamental truths about technical education. Learning proves enjoyable when rooted in passion projects. Failure constitutes an integral component of growth, yielding deeper insights than initial successes. Building tangible solutions to personal problems accelerates skill development far beyond theoretical study. Aspiring developers benefit immensely from identifying relevant challenges and iterating relentlessly toward mastery.
Links:
[DotJs2024] How to Test Web Applications
Tracing the sinews of testing evolution unveils a saga of ingenuity amid constraints, where manual pokes birthed automated sentinels. Jessica Sachs, a product-minded frontend engineer at Ionic with a penchant for vintage tech, chronicled this odyssey at dotJS 2024. From St. Augustine’s cobblestone allure—America’s eldest city, founded 1565—she drew parallels to web dev’s storied paths, unearthing undocumented timelines via Wayback Machine dives and Twitter lore. Sachs’s quest: demystify the proliferation of test runners, revealing how historical exigencies—from CGI pains to Node’s ascent—shaped today’s arsenal, advocating patience for tools that integrate seamlessly into workflows.
Sachs ignited with a Twitter thread amassing 178 responses, crowdsourcing pre-2011 practices. The ’90s dawned with CGI scripts in C or Perl, rendering dynamic content via URL params—a nightmare for verification. Absent browsers, coders FTP’d to prod, editing vi in situ, then paraded to webmasters’ desks for eyeball tests on finicky monitors. Issues skewed infrastructural: network glitches, deployment fumbles, not logic lapses. Enter Selenium circa 2011, Sachs’s genesis as manual QA tapping iPads, automating browser puppeteering. Predecessors? Fragmented: HTTPUnit for server mocks, early Selenium precursors like Kantara for JavaScript injection.
The aughts splintered further. jQuery’s 2006 surge spawned QUnit; Yahoo UI birthed YUITest; Scriptaculous, Ruby-infused, shipped bespoke runners amid TDD fervor. Pushback mounted: velocity killers, JS’s ancillary role to backend logic. Breakthrough: 2007’s JS Test Driver, Mishko’s Java-forged Google tool, spawning browsers, watching files, reporting terminals—paving for Testacular (Karma’s cheeky forebear). PhantomJS enabled headless CI, universally loathed yet indispensable till Node. Sachs unearthed Ryan Florence’s GitHub plea rebranding Testacular to Karma, easing corporate qualms.
Node’s 2011 arrival unified: Jest, open-sourced by Facebook in 2014 (conceived 2011), tackled module transforms, fake DOMs for builds. Sachs lauded its webpack foresight, supplanting concatenation. Yet, sprawl persists: Bun, Deno, edge functions defy file systems; ESM, TypeScript confound. Vitest ascends, context-switching via jsdom, HappyDOM, browser modes, E2E orchestration—bundler-agnostic, coupling to transformers sans custom ones. Sachs’s epiphany: runners mirror environments; history’s lessons—manual sufficed for Android pre-automation—affirm: prioritize speed, workflow harmony. Novel tools demand forbearance; value accrues organically.
Sachs’s tapestry reminds: testing’s not punitive but enabler, evolving from ad-hoc to ecosystem symbiote, ensuring robustness amid flux.
Unearthing Testing’s Archaic Roots
Sachs’s archival foray exposed ’90s drudgery: CGI’s prod edits via vi, manual verifications on webmaster rigs, network woes trumping semantics. Selenium’s 2011 automation eclipsed this, but antecedents like HTTPUnit hinted at mocks. The 2000s fragmented—YUITest, QUnit tying to libs—yet JS Test Driver unified, birthing Karma’s headless era via PhantomJS, Node’s prelude.
The Node Era and Modern Convergence
Jest’s 2014 debut addressed builds, modules; Vitest now reigns, emulating DOMs diversely, launching browsers, integrating E2E. Sachs spotlighted bundlers as logic proxies, ESM/TS as Jest’s Achilles; Vitest’s flexibility heralds adaptability. Android’s manual heritage validates: tools must accelerate, not hinder—foster adoption through velocity.
Links:
[DevoxxFR2013] Arquillian for Simple and Effective Web Tests
Lecturer
Alexis Hassler is a Java developer with over fifteen years of experience. He operates as an independent professional, engaging in coding, training, and supporting enterprises to enhance their Java development and deployment practices. As co-leader of the Lyon Java User Group, he contributes to community events like the Mix-IT conference in Lyon.
Abstract
Alexis Hassler’s session explores Arquillian’s capabilities for testing web applications, extending beyond Java EE components to comprehensive integration testing. Demonstrating extensions like Drone, Graphene, and Warp, he illustrates client-side and server-side testing methodologies. The discussion analyzes setup, execution, and benefits, emphasizing real-world testing that verifies both client interactions and server states for robust applications.
Core Concepts of Arquillian: Integration Testing Reversed
Hassler introduces Arquillian as a tool for integration testing Java EE components, defining a component as an entity like an EJB with injected dependencies, transactional, and security contexts. Unlike embedding containers in tests, Arquillian packages the component with tests and deploys to a container, inverting the process for realistic environments.
A basic test class uses JUnit with an Arquillian runner. The @Deployment annotation creates a testable archive (e.g., WAR) containing classes and resources. Methods like @Test execute within the container, accessing injected resources seamlessly.
This approach ensures tests run in production-like settings, catching issues early. Hassler contrasts with traditional unit tests, highlighting Arquillian’s focus on integrated behaviors.
Extending to Web Testing: Drone and Graphene for Client-Side Interactions
For web applications, Hassler leverages Drone and Graphene extensions, combining Arquillian’s deployment with Selenium’s browser automation. Drone instantiates WebDriver instances; Graphene enhances with guards for AJAX handling.
In setup, specify a managed container like JBoss AS in arquillian.xml. Tests deploy the app, then use @Drone-annotated browsers to interact: navigate via @ArquillianResource URLs, fill forms, assert outcomes.
Graphene’s guards wait for requests, ensuring reliable tests amid asynchronous behaviors. This client-mode testing (@RunAsClient) simulates user interactions, verifying HTTP responses without server-side access.
Code example:
@Drone
WebDriver browser;
@ArquillianResource
URL deploymentUrl;
@Test
@RunAsClient
public void testLogin() {
browser.get(deploymentUrl + "login.jsf");
// Interact and assert
}
This deploys, browses, and validates, bridging unit and functional testing.
Advanced Verification with Warp: Bridging Client and Server States
To inspect server-side states during client tests, Hassler introduces Warp. It wraps requests with payloads, executing inspections on the server before/after phases.
Define inspections extending WarpInspection, annotating with @WarpTest. Use @BeforeServlet/@AfterServlet for timing. Deploy via @WarpDeployment.
Example: Verify session attributes post-login. Client triggers action; Warp asserts server-side.
public class SessionInspection extends WarpInspection {
@AfterServlet
public void checkSession() {
// Assert session values
}
}
Warp enables “real tests” by combining client simulations with server validations, detecting mismatches invisible to pure client tests.
Hassler notes Warp’s alpha status, advising community forums for issues.
Implications for Development Practices: Flexibility and Community Support
Arquillian’s modularity allows mixing modes: @RunAsClient for web, in-container for components. This flexibility suits diverse apps, from simple servlets to complex JSF.
Challenges include initial setup—choosing extensions, versions, resolving conflicts. Documentation is evolving; forums on JBoss.org are responsive, often from developers.
Hassler encourages adoption for effective testing, reducing deployment surprises. Community involvement accelerates learning, fostering better practices.
In essence, Arquillian with extensions empowers thorough, efficient web testing, aligning development with production realities.