Selenium is a widely used open source framework for end-to-end web testing nowadays. JUnit 5 is the latest version of this popular Java open source unit testing framework and implements a brand-new programming and extension model named Jupiter. This talk presents Selenium-Jupiter. This is an open-source JUnit 5 extension that provides seamless integration with Selenium.
Software Testing Videos and Tutorials: Load Testing, Unit Testing, Functional Testing
If you are doing UI test automation, there is a high probability that you are using Selenium. Either directly, or in some framework, or by some tool that is built on Selenium. But did you ever wonder what is going on under the hood? How does Selenium use the browser? How does it find elements? If that sounds interesting to you, this is a presentation for you.
“TDD is a design tool.” That is what the presenter has said for years. But not anymore. After working with different teams and in different organizations, and also carefully inspecting how he works, he changed his mind about the role of Test-Driven Development (TDD) in software design.
The paradox: I cannot test this code because it is legacy. I need to refractor the code to make it testable. How can I manage that, without breaking existing functionality? I will need to write some tests, but… argh! This presentation explains how to safely refactor and test ‘untestable’ code – without breaking any existing functionality.
Creating test automation engineers from manual testers is hard. Even if your testers are willing, they have a lot of hurdles to get over to feel like the same kind of subject matter experts in automation as they are in manual testing.
Automated software testing is widely considered a best practice. After considerable effort, the software development industry now agrees that unit testing, system testing, usability, and performance testing are essential in most serious software development efforts, but we know that they are hard work.
Why are we afraid to deploy software on Friday evening? Well, mostly because no one wants to debug production issues on Saturday and we really want to go home. Answering the (seemingly) basic question of “does the code actually work?” is surprisingly difficult at times.