Test JavaScript. Test with JavaScript.

Coming into software with an exploratory testing mindset is like coming to a multi-layer canvas with lots of information and an open ended task: find what we may have missed! This is the assignment for us all in software teams in our quest for quality.

Framing the search of how our system falls short of expectations is easier when we are able to see software from its user’s perspective. However, useful tests aren’t a collection of end-to-end tests we automate, but great tests to leave behind will decompose the testing problem differently. In this talk, we learn about using architecture as a filter in decomposing tests and look at an example of taking control over the API responses to test a React frontend.

Users don’t know or care if the problem is in the frontend and services your team provided if it fails to meet their expectations but you care. Granularity of feedback matters. Recognizing the same problems in incomplete scope - half-done features or only in frontend or APIs - is a skillset the software industry needs to be building.

The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.

The adoption of open-source software continues to grow and creates significant security concerns for everything from software supply chain attacks in language ecosystem registries to cloud-native application security concerns. In this session, we will explore how developers are targeted as a vehicle for malware distribution, how immensely we depend on open-source maintainers to release timely security fixes, and how the race to the cloud creates new security concerns for developers to cope with, as computing resources turn into infrastructure as code.

Whether you’re testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level talk demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.

As an industry, we understand that effective test automation is a key enabler - or inhibitor to - realizing the potential of DevOps. While automation is critical to innovating with speed and quality, very few of us are happy with the results. This talk will cover how low-code test automation solutions - like mabl - enable teams to embed automated tests directly into the development pipeline, strategies to overcome traditional challenges with test automation, and how to build a foundation for an efficient and effective test strategy.

With StackHawk, engineering teams can run security tests against JS applications and the backing APIs to find and fix vulnerabilities faster. With automated testing on every PR, you can be confident that your app is secure. Join StackHawk co-founder Scott Gerlach for a quick overview of JS application security testing with StackHawk.

Nowadays, testing has become the norm. There are many tools available to write different kinds of tests. While tests keep the guard on the main code of the application, how can you be sure that you don’t have bugs hiding in your test code? Should you write tests for the tests?

In this lighting talk I will show you a different approach on how you can eliminate certain types of issues from your tests using static code analysis tools like SonarLint or SonarQube. We will focus on common issues found in tests using frameworks such as Mocha and Chai.

Contemporary software systems are often built on a microservices architecture pattern. In this pattern, rather than build one huge code-base for a single application, systems are separated into multiple smaller code-bases. These implement services that provide a specific feature, like authentication or monitoring, and those services can have performance problems, network issues, or bugs in their code – any of which can lead to failing tests. If you want to solve such problems, you have to go a step further than just logging your errors – it is best for you to monitor your tests with distributed tracing. This talk will show you why a tracing system will rescue you from the complexity of understanding why an E2E test has failed in a distributed architecture.

NeuraLegion's developer friendly security scanner enables development teams to run dead accurate security tests on every build as part of their pipeline. False alerts and periodic infrequent scanning results in technical and security debt, as well as insecure product. But what is developer first DAST, when and how should you be integrating it into your pipelines and what should you be looking for when enhancing your security testing automation? Join this talk to get up to date.

For modern agile teams, release velocity is very critical. Unfortunately, one of the biggest bottlenecks for faster release velocity is testing times. Even after teams implement end-to-end test automation, long testing times significantly delay the pipelines. This delay means developers get feedback of their efforts very late, which can snowball, affecting the shipping velocity. Hence test execution time becomes one of the most critical KPIs for any business that wants to ship features faster than the approaching deadlines. LambdaTest helps modern dev teams release faster by executing tests faster on a scalable, reliable test cloud.

Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!

• But how do we do that?
• Are the "unit" and "integration" terminology serves us right?
• Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?

In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!

It’s time to go DEEPER!

Selenium 4 is out and going forward Selenium Webdriver will be completely W3C standardized. Browsers such as Chrome, Safari, Firefox, IE and Edge follow W3C standardization, bringing more standard and stability around selenium commands working uniformly across different real browsers.

Join David Burns, Core Contributor to Selenium as he talks about how this would impact your tests and about the brilliant new features that you can start using straight away. David will show how you can access a site protected by basic authentication, identify a DOM mutation, get JS errors or console messages as they happen, use new Print and Window APIs to help with your testing and more.

This talk will cover how we can apply machine learning to software testing including in Javascript, to help reduce the number of tests that need to be run.

We can use predictive machine learning model to make an informed decision to rule out tests that are extremely unlikely to uncover an issue. This opens up a new, more efficient way of selecting tests.

It’s a trap” - a call or feeling we all might be familiar with, not only when it comes to Star Wars. It’s signalizing a sudden moment of noticing imminent danger. This situation is an excellent allegory for an unpleasant realization in testing. Imagine having the best intentions when it comes to testing but still ending up with tests failing to deliver you any value at all? Tests who are feeling like a pain to deal with?

When writing frontend tests, there are lots of pitfalls on the way. In sum, they can lead to lousy maintainability, slow execution time, and - in the worst-case - tests you cannot trust. But it doesn’t have to be that way. In this session, I will talk about developers’ common mistakes (including mine), at least from my experience. And, of course, on how to avoid them. Testing doesn’t need to be painful, after all.

This talk is about common mistakes people make when writing tests.

Mixing multiple concerns inside tests is tempting because it can feel like painting the whole picture. However, it obfuscates the root cause when a test fails. Setup methods are great but when developers are too focussed on keeping their tests DRY they can easily lead to test interdependence. Therefore, some principles we have learned to build our software we need to unlearn when it comes to testing.

The talk highlights more aspects like bloated tests which make it hard to figure out what they are about and proper usage of assertions to get better error messages.

Especially if you don't work with TDD it can be easy to come up with a test that looks good but stands in your way when it fails.

The talk will have a look at the four scenarios I outlined above, explain why it makes sense to think about them and actionable suggestions how to improve tests.

Visual Regression tests components via screenshot matching. I'll show how you do that in three different libraries/frameworks. Additionally, I will use Storybook to extract the components from your SPA of choice.

Having adequate test coverage means a lot for the good API. But what can make the whole life pathetic is endless mocking of data and functions for integration tests. Every time you've changed the code you need to fix the mock. After several iterations the correct thought is - what's went wrong?

Alternative approach is e2e tests for the API. Which require only minimal mocks and data preparation. The rest - pure code of your API. Change the code - e2e test remains the same.

This talk is about my experience of switching from integration tests to e2e tests for the API, proc and cons and how I started to feel happy about tests.

Have you ever wondered: "who's testing the tests"? Of course, tests are only valuable if they catch bugs, but how would one validate that? Well, let me tell you about mutation testing!

Mutation testing is the act of testing your test by verifying that they catch bugs. Of course, you can do this manually by inserting bugs and running the tests, but a mutation testing framework can do this for you!

Join me and learn the basics of mutation testing and how to use StrykerJS, the mutation testing framework for JavaScript or TypeScript.

At the end of this talk, you'll be the one that is testing your tests, and it won't even cost you much time!

For developers, it is better to catch any a11y defects during unit and e2e testings. This talk is going to show how to automate a11y testing using jest and cypress.

This lightning talk highlights Microsoft commitment to Javascript, and the Javascript community. TestJS Summit is something we look forward to this year.

The Javascript community is vibrant, diverse, and inclusive, and we love that we can help make TestJS happen and bring the community together, in a unique, online, way this year again.

Javascript is widely used and supported by many different teams at Microsoft. Moreover, several of our customers rely on our tools and platforms for their Javascript codebases.

Axe-core is a popular accessibility testing engine that is used by Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.

Imagine writing a complex function without unit tests. You would have to verify every scenario manually, over and over again. Cumbersome, but that's how most teams build user interfaces.

Imagine if you could build UIs and test UIs in the same place. If your components included expectations for how they were supposed to behave, you'd know the instant they broke.

Storybook provides an organized approach to building UIs. You document a component's use-cases as stories, which are then rendered in isolation. Stories are like tests, but for UI. Storybook interaction testing allows you to script interactions and check expectations in the story itself. That allows you to run and debug UI tests in the same environment UI components are developed for: your browser.

Performance testing is an expertise that is developed for a long time. In order to measure your server performance you need a tool that can efficiently simulate a lot of abilities and give you good measurements according your analysing criteria.

Autocannon NPM library gave me exactly that - that library is super easy to install and has a very simple API to work with. Within a really short amount of time you can start do performance testing to your application and get good measurements in development environment and in your performance labs, and generate complicated testing scenarios.

In this talk I will introduce Autocannon, explain how to efficiently analyse your server performance with it, and show how it helped me to understand complicated performance issues in my Node.js servers. At the end of this lecture, developers will be able to have the ability to integrate a fast and easy tool in order to measure your server performance.