time travel debugging c#

Using Time Travel Debugging (TTD)

Table of contents:

Description

Installation, accessing ttd data, querying debugging events, examining function calls, position in ttd trace, examining memory access.

TTD is a fantastic way to debug application code. After collecting a debug trace, we may query process memory, function calls, going deeper and deeper into the call stacks if necessary, and jump through various process lifetime events.

The collector is installed with WinDbgX and we may enable it when starting a WinDbgX debugging session.

Alternatively, we could install the command-line TTD collector . The PowerShell script published on the linked site is capable of installing TTD even on systems not supporting the MSIX installations. The command-line tool is probably the best option when collecting TTD traces on server systems. When done, you may uninstall the driver by using the -cleanup option.

If you have WinDbgX, you may use TTD by checking the “Record with Time Travel Debugging” checkbox when you start a new process or attach to a running one. When you stop the TTD trace in WinDbgX it will terminate the target process (TTD.exe, described later, can detach from a process without killing it).

An alternative to WinDbgX is running the command-line TTD collector. Some usage examples:

We can acess TTD objects by querying the TTD property of the session or process objects:

The @$curprocess.Events collection contains TTD Event objects . We can use the group query to learn what type of events we have in our trace:

Next, we may filter the list for events that interest us, for example, to extract the first TTD Exception object , we may run the following query:

The Calls method of the TTD objects allows us to query function calls made in the trace. We may use either an address or a symbol name (even with wildcards) as a parameter to the Calls method:

Thanks to wildcards , we can easily get statistics on function calls from a given module or modules (this call might take some time for longer traces):

TimeStart shows the position of a call in a trace and we may use it to jump between different places in the trace. SystemTimeStart shows the clock time of a given call:

Each function call has a Parameters property that gives us access to the function parameters (without private symbols, we can access the first four parameters) of a call:

The TTD Position object describes a moment in time in the trace. Its SeekTo method allows us to jump to this moment and analyze the process state:

If we are troubleshooting an issue spanning multiple processes, we may simultaneously record TTD traces for all of them, and later, use the TTD Position objects to set the same moment in time in all the traces. It is a very effective technique when debugging locking issues.

The Memory and MemoryForPositionRange methods of the TTD Session object return TTD Memory objects describing various operations on the memory. For example, the command below shows all the changes to the global GcInProgress variable in a .NET application:

The MemoryForPositionRange method allows us to additionally limit memory access queries to a specific time-range. It makes sense to use this method for scope-based addresses, such as function parameters or local variables. Below, you may see an example of a query when we list all the places in the CreateFileW function that read the file name (the first argument to the function):

• Some Time Travel musings - a great post by Axel Souchet presenting various techniques for analysing TTD traces

Time Travel Debugging is now available in WinDbg Preview

• James Pinkerton

We are excited to announce that Time Travel Debugging (TTD) features are now available in the latest version of WinDbg Preview.  About a month ago, we released  WinDbg  Preview ,  which provides great new debugging user experience s .  We are now  publicly launching   a preview version of  TTD  for the first time and are looking forward to your feedback.  

What is TTD?

Wouldn’t it be great to go back in time and fix a problem? We can’t help you go back in time to fix poor life choices, but we can help you go back in time to fix code problems.

Time Travel Debugging (TTD) is a reverse debugging solution that allows you to record the execution of an app or process, replay it both forwards and backwards and use queries to search through the entire trace. Today’s debuggers typically allow you to start at a specific point in time and only go forward. TTD improves debugging since you can go back in time to better understand the conditions that lead up to the bug. You can also replay it multiple times to learn how best to fix the problem.

TTD is as easy as 1 – 2 – 3.

• Record:  Record the app or process on the machine which can reproduce the bug. This creates a Trace file (.RUN extension) which has all of the information to reproduce the bug.
• Replay:  Open the Trace file in WinDbg Preview and replay the code execution both forward and backward as many times as necessary to understand the problem.
• Analyze:  Run queries & commands to identify common code issues and have full access to memory and locals to understand what is going on.

Getting Started

I know you are all excited and ready to start using TTD. Here are a few things you should know to get started.

• Install :  You can use TTD by installing the WinDbg Preview (build 10.0.16365.1002 or greater) from the Store if you have Windows 10 Anniversary Update or newer at  https://aka.ms/WinDbgPreview .
• Feedback:  This is a preview release of TTD, so we are counting on your feedback as we continue to finish the product. We are using the Feedback Hub to help us prioritize what improvements to make. The Windows Insider website has a great overview on how to give good feedback  https://insider.windows.com/en-us/how-to-feedback .
• Questions :  We expect you will have some questions as you work with TTD. So feel free to post them on this blog or send them in the Feedback Hub and we will do our best to answer. We’ll be posting a TTD FAQ on our blog shortly.
• Documentation :  We’ve got some initial documentation at  https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview  and will be improving our content based upon customer feedback and usage. You can give us feedback or propose edits on the docs.microsoft.com documentation by hitting “Comments” or “Edit” on any page.
• Blog s:  Watch for more in-depth TTD updates and tips in the future on our team’s blog  https://blogs.msdn.microsoft.com/windbg .

How to use TTD

You use TTD directly in the WinDbg Preview app. We have added all of the key TTD features into WinDbg Preview to provide a familiar debugging experience, which makes it intuitive to go backwards and forwards in time during your debugging session.

Record a Trace

WinDbg Preview makes it easy to record a trace. Simply click File >> Start Debugging and point to the app or process. You will have an option to Record during attach and launch. See  https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview  for more information.

Replay a Trace

Once the Trace is complete, we automatically load and index the Trace for faster replay and memory lookups. Then simply use the WinDbg ribbon buttons or commands to step forwards and backwards through the code.

Basic TTD Commands

You can use the ribbon or enter the following TTD commands in WinDbg Preview. See  https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview  for a complete list of TTD commands.

Final Thoughts

We are very excited to get TTD into the hands of our developers; but there are a few things to remember.

• TTD is a preview, so we will be regularly improving performance and features
• This only runs on Windows 10 since WinDbg Preview is a Store app
• See docs.microsoft.com documentation for TTD known issues and compatibility

Welcome to the world of time travel. Our goal is to improve the lives of developers by making debugging easier to increase product quality. Please send us feedback and feature requests in the Feedback Hub to let us know how we are doing!

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Time Travel Debugging

In this episode, Robert is joined by Mark Downie , who shows us Time Travel Debugging . provides the ability to record a Web app running on a Azure Virtual Machine (VM) and then accurately reconstruct and replay the execution path. You can record code executed in production and replay the execution path inside Visual Studio. TTD also gives you the ability to move forward and backwards in time as if you were performing "inner loop" debugging locally.

• Introducing Time Travel Debugging for Visual Studio Enterprise 2019
• Record and replay live ASP.NET apps on Azure virtual machines using the Snapshot Debugger

Have feedback? Submit an issue here .

Try RevDeBug in action for free. Jump into our interactive demo >

Debugging multilevel applications in C#

By RevDeBug

Just like “Back to The Future” is a movie that is considered to be a symbolic part of the 90s, the same way bugs are inherent in development. It is especially true with multilayer applications where finding a bug may be a real challenge. Even with all kinds of tests, various bugs slip into production now and then. Is there some way to inspect them in the production environment? How to find out what happened on your clients’ machine? This article contains a short tour of RevDeBug – Time Machine for Visual Studio. Check it out!

What is time travel debugging?

Standard Visual Studio debugging tool contains instruments such as step-into, step-over, or step-out. Reverse debugging allows you to travel in the opposite direction to inspect what causes the bug in your project. This infographic gives you a simple explanation of this process:

Reverse debugging tool for Visual Studio

RevDeBug is a Visual Studio extension for C# frameworks, which allows you not only to implement reverse debugging in your projects but also to monitor them on production. It creates a recording with all application states (values, methods calls, exceptions). With this information, you will be able to easily travel back in time, through every layer of your code. How does it work in practice? We may summarize that to these two steps:

• Recording  of a session with a bug is being sent automatically from application user to developer.
• The developer  is prospecting this stream of values  to find the root of the problem.

Travel in code, in the order of its execution time.

Track every strand of your application, basing on data from production.

It’s not the only feature of RevDeBug, which supports developers in debugging complex applications. With the latest update, we give you also a call stack and scope stack (which provides fine-grained navigation within the current method and makes it easier to iterate over loops and conditionals).

RevDeBug call stack is a tool that gives you detailed information about methods called at runtime from the beginning of a program until the execution of the current state.

Time traveling is only one function of RevDeBug, an advanced reverse debugger for c# applications. Want to know more? Check out our other articles:

How to use RevDeBug performance profiler?

Infographic: How to debug on production?

How to debug mobile apps on production?

Subscribe to receive our newsletters

6 Things You Need to Know About Time Travel Debugging

What is time travel debugging.

Time travel debugging (aka  reverse debugging ) enables developers to record all program activities at runtime (every memory access, every computation, and every call to the operating system), and then rewind and replay to inspect the program state.

This huge amount of data can be described using a powerful metaphor: the ability to travel backward in time (and forward again) to inspect the program state.

Typically, in order to optimize for performance, the developers will fine tune the time travel debugger to collect only the information necessary for accurate replay of the program under inspection.

Time travel debuggers vs traditional debuggers

Traditional debuggers  let you step line-by-line, forward, through a program and watch for a bug. This a approach can work well for very simple bugs, where the crash happens on the same line as, or immediately after, the error.

Sometimes, the location of an error and a developer’s knowledge of the code may suggest one or more possible locations to start looking for the root cause, so that when you restart the program in the debugger and run it forward, you can start looking at the logic around these locations to see where it goes off track.

However, this guesswork approach is much harder to apply in the case of hard to reproduce bugs, where a developer may have little/no information available about why the bug came about.

Time travel debuggers are the single most helpful solution for these types of failures as a programmer can replay and walk through the program’s execution backward, as well as forward, in order to home in on a point of interest.

This enables them to find the root cause from two ends of the program instead of one.

How does time travel debugging compare with runtime debugging?

Runtime debugging  is the common practice of forwards-only debugging. It is the mixture of breakpoints, watchpoints and other general runtime-debugger things that serve as bookmarks to help you find bugs in your software.

You can run your program until it hits a breakpoint and analyze any issues that appear in that particular section of code.

In some cases, this works fine, but more often than not, you do not know what section of code caused the error. This is a major problem when programs are large and makes it time-consuming to run them again and again.

With time travel debugging, a developer only has to run their program once in order to capture a complete record of the program’s execution – including any error that appeared during runtime – in a recording.

A recording not only captures the bug itself, but more importantly, the sequence of events that led up to and caused it.

How does time travel debugging work?

Developers have adopted different methods for time travel debugging and there is much discussion about how it works (see for example the StackExchange thread  How does reverse debugging work? ).

Taking Undo as an example, Undo’s time travel debugger called  UDB , provides the ability to instruct the process to go to any previous point in the execution history.

It relies on the fact that many operations in a computer are actually deterministic and uses these as a way of identifying all sources of non-determinism that appear in compiled code (for more information, see  introduction to reverse debugging ).

This allows developers to address the most time-consuming aspects of debugging today’s multilevel, multicomponent, multithreaded and multi-process applications.

How does time travel debugging affect performance?

Some slowdown must be expected when using time travel debugging (see for example the points raised on StackExchange in the thread  Why is reverse debugging rarely used? ).

However, this varies hugely depending on the method of time travel debugging used.  The time travel debugging function of GDB, for example, can slow a program down 50,000x, which is far too slow to be considered by most developers.  UDB , typically causes a slowdown of 2-3x (though for large complex code systems, this can be greater).

However, it is important to remember that you will have to restart your program multiple times when using a conventional debugger whereas with time travel debuggers such as UDB, you can replay backward and forward as often as you need without having to restart.

Can you use time travel debugging in any programming language?

Yes . Most Time Travel Debuggers for compiled code are based on the GNU debugger, GDB, and therefore support all  languages compatible with GDB  (e.g. C/C++, Go and even Fortran). For other languages, there are a growing number approaches to time travel debugging tools, such as:

Time travel debugging for Python ( PyTrace ) Time travel debugging for JavaScript ( Wallaby.js ) Reverse debugging for .Net and C# ( RevDeBug ) Time travel debugging for web applications ( Replay.io ) Reverse debugging for Python ( RevPDB ) Time Travel Debugging for Elm (Elm TTD)

Stay informed. Get the latest in your inbox.

Hit enter to search or ESC to close

Time-Travel Debugging Production Code

Loren Sands-Ramshaw

Developer Relations Engineer

In this post, I’ll give an overview of time-travel debugging (what it is, its history, how it’s implemented) and show how it relates to debugging your production code.

Normally, when we use debuggers, we set a breakpoint on a line of code, we run our code, execution pauses on our breakpoint, we look at values of variables and maybe the call stack, and then we manually step forward through our code’s execution. In time-travel debugging , also known as reverse debugging , we can step backward as well as forward. This is powerful because debugging is an exercise in figuring out what happened: traditional debuggers are good at telling you what your program is doing right now, whereas time-travel debuggers let you see what happened. You can wind back to any line of code that executed and see the full program state at any point in your program’s history.

History and current state

It all started with Smalltalk-76, developed in 1976 at Xerox PARC . ( Everything started at PARC 😄.) It had the ability to retrospectively inspect checkpointed places in execution. Around 1980, MIT added a “retrograde motion” command to its DDT debugger , which gave a limited ability to move backward through execution. In a 1995 paper, MIT researchers released ZStep 95, the first true reverse debugger, which recorded all operations as they were performed and supported stepping backward, reverting the system to the previous state. However, it was a research tool and not widely adopted outside academia.

ODB, the Omniscient Debugger , was a Java reverse debugger that was introduced in 2003, marking the first instance of time-travel debugging in a widely used programming language. GDB (perhaps the most well-known command-line debugger, used mostly with C/C++) added it in 2009.

Now, time-travel debugging is available for many languages, platforms, and IDEs, including:

• Replay for JavaScript in Chrome, Firefox, and Node, and Wallaby for tests in Node
• WinDbg for Windows applications
• rr for C, C++, Rust, Go, and others on Linux
• Undo for C, C++, Java, Kotlin, Rust, and Go on Linux
• Various extensions (often rr- or Undo-based) for Visual Studio, VS Code, JetBrains IDEs, Emacs, etc.

Implementation techniques

There are three main approaches to implementing time-travel debugging:

• Record & Replay : Record all non-deterministic inputs to a program during its execution. Then, during the debug phase, the program can be deterministically replayed using the recorded inputs in order to reconstruct any prior state.
• Snapshotting : Periodically take snapshots of a program’s entire state. During debugging, the program can be rolled back to these saved states. This method can be memory-intensive because it involves storing the entire state of the program at multiple points in time.
• Instrumentation : Add extra code to the program that logs changes in its state. This extra code allows the debugger to step the program backwards by reverting changes. However, this approach can significantly slow down the program’s execution.

rr uses the first (the rr name stands for Record and Replay), as does Replay . WinDbg uses the first two, and Undo uses all three (see how it differs from rr ).

Time-traveling in production

Traditionally, running a debugger in prod doesn’t make much sense. Sure, we could SSH into a prod machine and start the process handling requests with a debugger and a breakpoint, but once we hit the breakpoint, we’re delaying responses to all current requests and unable to respond to new requests. Also, debugging non-trivial issues is an iterative process: we get a clue, we keep looking and find more clues; discovery of each clue is typically rerunning the program and reproducing the failure. So, instead of debugging in production, what we do is replicate on our dev machine whatever issue we’re investigating and use a debugger locally (or, more often, add log statements 😄), and re-run as many times as required to figure it out. Replicating takes time (and in some cases a lot of time, and in some cases infinite time), so it would be really useful if we didn’t have to.

While running traditional debuggers doesn’t make sense, time-travel debuggers can record a process execution on one machine and replay it on another machine. So we can record (or snapshot or instrument) production and replay it on our dev machine for debugging (depending on the tool, our machine may need to have the same CPU instruction set as prod). However, the recording step generally doesn’t make sense to use in prod given the high amount of overhead—if we set up recording and then have to use ten times as many servers to handle the same load, whoever pays our AWS bill will not be happy 😁.

But there are a couple scenarios in which it does make sense:

• Undo only slows down execution 2–5x , so while we don’t want to leave it on just in case, we can turn it on temporarily on a subset of prod processes for hard-to-repro bugs until we have captured the bug happening, and then we turn it off.
• When we’re already recording the execution of a program in the normal course of operation.

The rest of this post is about #2, which is a way of running programs called durable execution .

Durable execution

What’s that.

First, a brief backstory. After Amazon (one of the first large adopters of microservices) decided that using message queues to communicate between services was not the way to go (hear the story first-hand here ), they started using orchestration. And once they realized defining orchestration logic in YAML/JSON wasn’t a good developer experience, they created AWS Simple Workfow Service to define logic in code. This technique of backing code by an orchestration engine is called durable execution, and it spread to Azure Durable Functions , Cadence (used at Uber for > 1,000 services ), and Temporal (used by Stripe, Netflix, Datadog, Snap, Coinbase, and many more).

Durable execution runs code durably—recording each step in a database, so that when anything fails, it can be retried from the same step. The machine running the function can even lose power before it gets to line 10, and another process is guaranteed to pick up executing at line 10, with all variables and threads intact.[^1] It does this with a form of record & replay: all input from the outside is recorded, so when the second process picks up the partially-executed function, it can replay the code (in a side-effect–free manner) with the recorded input in order to get the code into the right state by line 10.

Durable execution’s flavor of record & replay doesn’t use high-overhead methods like software JIT binary translation , snapshotting, or instrumentation. It also doesn’t require special hardware. It does require one constraint: durable code must be deterministic (i.e., given the same input, it must take the same code path). So it can’t do things that might have different results at different times, like use the network or disk. However, it can call other functions that are run normally ( “volatile functions” , as we like to call them 😄), and while each step of those functions isn’t persisted, the functions are automatically retried on transient failures (like a service being down).

Only the steps that require interacting with the outside world (like calling a volatile function, or calling sleep('30 days') , which stores a timer in the database) are persisted. Their results are also persisted, so that when you replay the durable function that died on line 10, if it previously called the volatile function on line 5 that returned “foo”, during replay, “foo” will immediately be returned (instead of the volatile function getting called again). While yes, it adds latency to be saving things to the database, Temporal supports extremely high throughput (tested up to a million recorded steps per second). And in addition to function recoverability and automatic retries, it comes with many more benefits , including extraordinary visibility into and debuggability of production.

Debugging prod

With durable execution, we can read through the steps that every single durable function took in production. We can also download the execution’s history, checkout the version of the code that’s running in prod, and pass the file to a replayer (Temporal has runtimes for Go, Java, JavaScript, Python, .NET, and PHP) so we can see in a debugger exactly what the code did during that production function execution. Read this post or watch this video to see an example in VS Code.[^2]

Being able to debug any past production code is a huge step up from the other option (finding a bug, trying to repro locally, failing, turning on Undo recording in prod until it happens again, turning it off, then debugging locally). It’s also a (sometimes necessary) step up from distributed tracing.

💬 Discuss on Hacker News , Reddit , Twitter , or LinkedIn .

I hope you found this post interesting! If you’d like to learn more about durable execution, I recommend reading:

• Building reliable distributed systems
• How durable execution works

and watching:

• Introduction to Temporal
• Why durable execution changes everything

Thanks to Greg Law, Jason Laster, Chad Retz, and Fitz for reviewing drafts of this post.

[^1]: Technically, it doesn’t have line-by-line granularity. It only records certain steps that the code takes—read on for more info ☺️. [^2]: The astute reader may note that our extension uses the default VS Code debugger, which doesn’t have a back button 😄. I transitioned from talking about TTD to methods of debugging production code via recording, so while Temporal doesn’t have TTD yet, it does record all the non-deterministic inputs to the program and is able to replay execution, so it’s definitely possible to implement. Upvote this issue or comment if you have thoughts on implementation!

DEV Community

Posted on May 5, 2023 • Updated on May 10, 2023

Playwright's UI Mode - watch mode and time travel debugging

Are you looking for a more efficient way to execute and debug your end to end tests? Look no further than Playwright's UI Mode . In this guide, we'll explore the features of Playwright's UI Mode and show you how to take advantage of them for your test automation needs. UI mode is only available when using Playwright with Node.js and not with Python, Java or C#.

What is UI Mode?

UI Mode is a powerful graphical user interface that provides a comprehensive trace of each of your tests. With UI Mode, you can explore, run, and debug your tests effortlessly with its time-traveling capabilities. The user-friendly interface enables you to view detailed test results, including logs, DOM snapshots, and trace information.

In addition, UI Mode comes equipped with watch mode, which allows you to monitor any of your tests and automatically rerun them on every code change, providing an optimal developer experience.

Overall, Playwright's UI Mode provides a comprehensive, user-friendly testing experience that allows you to identify and fix issues with your tests quickly and easily.

How to Use UI Mode?

To use UI Mode, you need to run the following command:

When you launch UI Mode, you'll see a list of all your test files. To run your tests, you have several options: click the triangle icon in the sidebar to run all of your tests, hover over a test file's name, and click on the triangle next to it to run a single test, a block of tests, or an entire test file.

Filtering Tests in UI Mode

You can filter tests by text or @tag, by passed, failed, or skipped tests, and by projects as set in your playwright.config file. If you are using project dependencies, make sure to run your setup tests first before running the tests that depend on them. The UI Mode will not take into consideration the setup tests, so you will have to manually run them first.

Viewing Test Traces

Traces provide detailed information about each test that has been executed. You can access the trace results by clicking on any of the individual test names. By examining the trace results, you can identify the cause of any failures or errors that occurred during the test run and take appropriate action to address them.

Actions and Metadata

The Actions tab provides valuable insights into your test execution. You can view the specific locator used for each action and the time taken to complete it. When you hover over each action, you can observe the changes in the DOM snapshot. Additionally, you can navigate backward and forward in time, and click on any action to inspect and debug it. The Before and After tabs allow you to visually track the changes that occurred before and after each action.

Adjacent to the Actions tab, you'll find the Metadata tab. This tab provides you with additional information on your test, such as the browser used, viewport size, test duration, and more.

Source, Console, Log, and Network

When hovering over a test action, its corresponding source code is highlighted below. To view the entire test's source code, click the "source" tab. Console logs and network logs for each action can be accessed by clicking the "console" and "network" tabs, respectively.

Pop Out and Inspect the DOM

To enhance your debugging experience, you can pop out the DOM snapshot by clicking the dedicated icon located above it. This will open the snapshot in a separate window where you can inspect HTML, CSS, and more using the browser DevTools. You can then go back to UI Mode and pop out another action's snapshot to compare or debug them side by side.

Timeline View

At the top of the trace, you can see a timeline view of each action of your test. Hover back and forth to see an image snapshot for each action.

Pick Locator

One of the most important parts of automated testing is identifying the elements on the page that you want to interact with. The Pick Locator feature in Playwright's UI Mode makes this process much easier by allowing you to easily select an element and retrieve its locator.

To use Pick Locator, simply click on the Pick Locator button in the UI Mode toolbar. This will activate the feature and highlight all the elements on the page as you hover over them. Once you click on a element the corresponding locator will be displayed in the Pick Locator field. Click on the copy button and then paste the locator into your test.

Watch Mode is another useful feature in Playwright's UI Mode that allows you to automatically re-run your tests as you make changes to your code. This can be particularly helpful when you are working on a large test suite and want to quickly test a change you've made without having to manually re-run the tests every time.

To use Watch Mode, simply click on the Eye icon next to the name of the test you want to watch. This will activate the feature and automatically re-run the test whenever you make changes to its code. You can watch multiple tests at the same time by clicking on the Eye icon next to each test, or you can watch all the tests in your test suite by clicking on the Eye icon at the top of the sidebar.

If you are using VS Code, you can easily open the test file in the editor by clicking on the File icon next to the Eye icon. This will open the test file in VS Code and take you directly to the line of code that corresponds to the test step you are currently watching.

In conclusion, Playwright's UI Mode offers a powerful set of tools for exploring, running, and debugging your automated tests. The time travel experience, complete with watch mode, filtering, and tracing, allows you to quickly identify and fix issues in your test code, while the Pick Locator feature simplifies the process of selecting and interacting with elements on the page. Whether you're a seasoned automated testing pro or just getting started with test automation, Playwright's UI Mode is definitely worth checking out.

Useful links

• UI Mode docs
• UI Mode video
• Playwright on Discord
• Star us on GitHub

Top comments (6)

Templates let you quickly answer FAQs or store snippets for re-use.

• Location Denver, CO, USA
• Education University of Colorado - twice!
• Work Test Automation Architect at a small company
• Joined Jan 7, 2023

With Python, playwright gives the error "error: unknown command 'test'". I suspect this feature only works with one of the four languages Playwright supports. If so, it's probably worth mentioning in the article.

• Location Spain
• Education Frontend Tech Degree at OpenClassrooms, Fullstack Tech Degree at Treehouse
• Work Senior Technical Program manager at Microsoft
• Joined Aug 15, 2019

thanks for recommendation. updated the article to reflect that it only works when using playwright in node.js and not with other languages

• Joined Dec 19, 2023

Playwright UI does not show the tests even though the tests are in proper folder as mentioned in the config file. It always goes Infinite loading… . Here the playwright Ui is hosted as an application and it is running in a pod of a node of kube Cluster

• Location La Habana, Cuba
• Education Universidad de las Ciencias Informáticas (UCI)
• Pronouns Yordani
• Work QA Automation
• Joined May 22, 2023

Hi Debbie. I am writing to see if you can help me with any ideas. I'm trying to implement some tests with Playwright but I need to pass two factor authentication. Is there a way to do it with the tool?

Greetings. Yordani!!!

• Joined May 5, 2023

I'm using cucumber with Playwright at my project. Is there any way to run cucumber tests with playwright in this --ui mode? I tried running it in my project, but it didn't work.

i am afraid not at the moment. but you can fill out a feature request on GitHub

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

AI+Node.js x-crawl crawler: Why are traditional crawlers no longer the first choice for data crawling?

CoderHXL - Apr 17

How to create Unit tests for code design?

Mark Andreev - Apr 15

Learn Web Scraping with Cheerio

peytono - Apr 14

The difference between '||' and '??' in JavaScript.

Emmanuel (Emmo00) - Apr 12

We're a place where coders share, stay up-to-date and grow their careers.

Sign up for Pure Virtual C++ 2024; the free, one-day, virtual conference for the whole C++ community.

How to use GitHub Copilot Chat in Visual Studio

Cynthia Zanoni

Laurent Bugnion

April 16th, 2024 2

GitHub Copilot serves as an AI-powered coding assistant capable of operating across various development environments, assisting you with your everyday coding challenges. In this new series of content, we will demonstrate how GitHub Copilot functions in Visual Studio especially and how it boosts your efficiency.

We just published “Using GitHub Copilot Chat in Visual Studio”, the third short video in this series, to guide you through leveraging GitHub Copilot Chat effectively within Visual Studio.

Exploring code with GitHub Copilot Chat

In the video, my coworker Bruno Capuano demonstrates how to populate an array with random numbers. Arrays are nice, but C# has more to offer and has other classes that can be used to make lists, with different features. GitHub Copilot Chat is a useful tool for this kind of investigations.

Make sure to have GitHub Copilot installed, refer to the documentation to learn how to install GitHub Copilot Chat for Visual Studio.

GitHub Copilot Chat can help you understand the difference between arrays and Lists. For example, it can list some of the differences, such as:

• The size (an array has a fixed-size structure while a List can change its size at runtime).
• The performance, a very important factor (arrays are usually more efficient than Lists because they don’t have to deal with dynamic sizing).
• The functionality (a List has more methods than an array, allowing for data manipulation)

Also, it can show you some code examples that show how to create an array and a List, and how to add one element.

You don’t need to tell Copilot chat that you are using C# and .NET. It can figure that out from the solution and the file you are working on. This is similar to how you would talk to another coder when you are pair-programming.

Converting code

In the following example, Bruno wants Copilot Chat to change his code, which uses arrays at first, to use Lists instead. A very handy feature that I personally find very useful is the preview feature . You just need to click the Preview button, and the code will be displayed inline in the code file, in a nice “diff” view that looks like what you see when comparing code changes, for example after a GitHub commit.

I think it’s a great way to see exactly what code will be modified, and most importantly, to check the code generated by Copilot before applying the changes. As we always remind you in this series, this is a Copilot, but you are the Pilot in Command!

I followed the example that Bruno demonstrated, and here is the code that Copilot Chat suggested to me before and after the changes:

Now that you have successfully installed GitHub Copilot in Visual Studio, you can now enjoy the benefits of AI-powered coding assistance. GitHub Copilot can help you write code faster and you can also learn from the suggestions and examples that GitHub Copilot provides. To learn more about GitHub Copilot and how to use it, check our collection with resources here  or via our  full-length video .

Additional Resources

• Code Faster and Better with GitHub Copilot’s New Features: Slash Commands and Context Variables
• Announcing the GitHub Extension for Visual Studio

Cynthia Zanoni Cloud Advocate, Developer Relations

Laurent Bugnion Principal Cloud Advocate, Developer Relations