So, our next speaker is Joe Ecker from the Salc Institute, and he's going to give an overview of the ENCODE PI's vision for functional genomics. You've received a copy of this document by email and also in your folder. Thanks, Joe. Yeah. So, I, as Elise said, this is a document that's been in the works for a few months and not actually seen by all PI's yet, so it's somewhat of a work in progress. I wanted to acknowledge Brad, Bernstein, David, Gifford, Mike Snyder, John Stambe, Barbara Wold for their input, so this has already been discussed. It's part of our document as well, describing what the accomplishments were. I don't think this was pulled out by Mike. This actually, I think, has a huge impact. Studying students and fellows, attending the phone calls every other week of the analysis group or whatever group you're part of, I think is real value. They get to hear the discussion, the criticisms, the data presentations. It's a really different new generation of students, a new generation of wave-doing science. Actually, I think it's a really important aspect of the project. As was mentioned, so Mike went through the various encode phases. The matrix is enormous, right? If you think about all cells, all assays, the matrix can be very large. There are some obvious things. I think the limitation in what we'll be able to do will be sort of access and reagent-based, obviously, access to certain cell types, reagent-based, but the community will have an input in terms of development of assays that reduce the numbers of cells that I think could change the matrix. We can't fixate on necessarily what's possible to do now, but maybe what might be possible with additional technology development. Really we have, I think, so far a catalog, not necessarily an encyclopedia. The definition of here of a catalog is sort of collections of items, pictures, et cetera. We have maps, right? We have different tissues. We have maps. We also have some integration of that and the attempt to generate knowledge. But the encyclopedia, I think, and this is also represented in the document, is really a deeper level of information about a particular element. I think to get to that level, you need function. You really need to assess the function of some of these elements, and that's part of where I think the PIs feel the project should go. These are the challenges, despite all the progress that you've heard about, the task of identifying all the functional elements is really not fulfilled yet. The more experiments to do, we actually haven't plateaued at finding different biochemical regions of interest alone assessing their function. There's an unexpected greater, I would say relatively unexpected, greater degree of diversity of the numbers and the molecular signatures that have been identified, and so that poses an enormous challenge for the next phase to try and understand how to attack and prioritize which of these biochemical activities to address with function. And already you've heard that it's been useful, it will continue to be useful when associated with genetic information. So the next phase of this project must leverage and integrate emerging technologies. You've heard about some reducing the amount of samples or imaging kinds of things, potentially, that you could take advantage. Any year I can't do everything, but to attack, for example, cell differentiation in a biological context, the time dimension so far has really been missing from the project, and that's certainly recognized by the PIs as an area that will be of interest, so perturbation to some extent, cell differentiation will give us potentially new ways of assigning correlating element requirement and biochemical activity. So high throughput approaches for mapping genomic features is going to be complimented by needing new tools that will allow us to assess function, so genome engineering and systematic functional perturbation are on the radar of the PIs for the possible next phase. So essentially four layers of information for this encode 2020 vision from elements to function are articulated. Layer one is completing the catalog of the elements. Layer two is connecting, there's some fine grain information in here that you could lump some of these things together differently, but I think PIs felt that connecting elements with their cognate genes is a challenge in and of itself that it warranted not being part of the catalog, but actually another unique layer of information. And then transforming this catalog of elements into the encyclopedia where you actually have knowledge about a particular element in a particular cell type and its function in terms of regulating the expression of the gene, the elongation of the polymerase, et cetera, whatever activity that has splicing, assisting other kinds of biochemical activities really will make this catalog into an encyclopedia. And then really to take this to yet another higher level to begin to address and I think Rick and Mark will discuss some of this because it was more related to genetic variation associating the variants with these elements and the impact on individual phenotypes and disease is kind of another layer that we think is going to be essential. So completing the catalog of elements is going to require new cell and tissue types. I think if you look at the textbooks and the recent literature, you know, there's about 400 cell types recognized, but if you look at complex tissues like brain and you start to dissect those apart, which I'll briefly mention, there's likely to be many more. So the number is probably much higher than that depending on how you define a cell subtype. New types of elements, the PIs believe and I think that there's reasonable expectation that what we're pointing to in terms of what kind of elements exist is based on sort of looking back at the literature and saying there's enhancers, silencers, et cetera, but that doesn't leave any room for new element discovery. So there's lots of potential discovery of new element types, especially when you layer on functional experiments on top of this. And then we really haven't in this project gotten into so much condition specific experiments where either developmental programs, I think Aviv had some really nice papers, I think transcriptional anticipation, for example, a factor binds but is not needed until some later stage will give us some more information about elements that you can recognize biochemically but don't seem to have a function at a particular stage because you haven't seen the requirement for that element during development or during a stress response or other kind of perturbation. So some features of what you heard in the links but more focused on the assays that ENCODE group is doing. So what's going to be required? A new generation of mapping and discovery tools. So this is likely to help with the problem of cell diversity in terms of the numbers so new technology should be part of the program. A feature of ENCODE is that the kinds of experiments that are done are typically beyond what individual laboratory can do and that's part of the interesting consortium activities. That is there's many high throughput experiments that are done with high quality and low cost so that provides the resource aspect to the project. So maintaining, actually increasing the throughput is also a goal. This addresses what Paul said about cost, try to drive the cost to down. The numbers of cells are clearly on the radar. It's challenging for some assays but there have been improvements in the assays through some of the technology development groups as well as some of the production groups and pushing down the numbers of cells that will allow you to get meaningful information from these different compartments. And then one important aspect is that if assays are developed with lower numbers of cells we don't want to really erode the quality. It was mentioned, I think Dana mentioned that the quality of the data is very high and we don't want the drive to get one cell without having high quality for that information as well. So although you can say single cell, some of the single cell assays that have been developed don't really cover the genome or only subsample a fraction of the information more or less randomly in each cell, so we have to be aware of that. The other thing is that there are, this was mentioned also, so I'm sort of saying things that I've already mentioned, this idea of having a community focused, not necessarily encode focused data coordination center where any individual from the community can go, I think we're headed there with the DCC we have, it really is a tremendous resource. People I know at the Salk use it all the time and you can go and find things, search things, but then equally having a similar resource that integrates the other data from the other groups in a way that allows a seamless sort of interaction among sort of high level users. Okay, I don't want to have to go to all the different databases, I want to be able to pull down from this tissue, this time, et cetera, all the raw data or the process data. So this is another resource that we think would be really useful. And these two resources will cover high level users down to individual investigators and really the resources that are here are very high quality, but if you can't utilize them, the individual laboratory can't utilize them or even the high power user can't utilize them in an efficient way that detracts from some of the value. So this next layer that has been discussed is really trying to associate these elements with their genes and as an important piece of information that we think is a separate activity related to some of the other things that are mentioned by Mike, for example, but these are high throughput. So these kinds of interactions are genome wide, long range, short range, and testing some of these long range interactions once they're identified, testing their functions. So some of the approaches for doing this or what's been going on is there are better, maybe more computationally efficient ways to do this, but activity correlation, physical interaction and then functional assays where you knock out the genome go through each one of these. So activity correlation is associating these biochemical activities with other features like promoter activity, so enhancer and promoter activity, that is chromatin marks or other kinds of biochemical activities, the enamelation on those, and associating them together to identify cell type, tissue type, selective events where you have this particular enhancer has a biochemical activity in this cell and that and an associated promoter, but not in that cell. So that's the kind of thing that ENCODE has been doing and these sorts of maps are activity correlation maps with different assays. The physical interactions are also beginning to emerge, they're certainly used in individual laboratories and are being beginning to be included in some high throughput approaches. We're directly linking promoter and distal elements. Some of the approaches are here. That doesn't mean these are limiting to these assays, new assays that may be equally efficient or higher resolution might be possible and understanding which of these assays in which conditions are going to be useful is also potential for technology development area. And this just shows an example of the kind of assay that can be carried out. It really hasn't been yet necessarily implemented in high throughput of a high C experiment where you're looking at domains of interaction across the chromosome and this allows you to begin to associate long distance regulatory elements and that's been useful already in some disease focused applications. So also there's knockout, so obviously reverse genetics is focused on elements, the functionality of elements is going to be very powerful, particularly Cas9 or CRISPR or other ways of mutating elements and this is being done again in individual laboratories but really hasn't yet been implemented by ENCODE or as far as I know other groups, large consortia to test for example the requirements of motifs either by altering a motif with a specific event, a mutational event or deleting completely an enhancer. This will allow us to begin to associate some of the biochemical activities with function. Where that function exists in the genome is going to be challenging because that element might affect the activity of polymerase whether it's stalled or not or what the initiation rate etc. So having assays that are downstream of these functional events, deletion events is going to be important. So this is an experiment obviously that you can do in mouse, you can create crosses and identify deletion, you can create deletion events that are on one chromosome so you have an enhancer associated with a particular SNP by mutation or deletion in whatever the case. You can have haplotypes that are derived that are associated with, that is from individuals that have SNPs that are associated with promoters and this can be done either by looking at natural populations in mouse or people or creating them and I think the point of where ENCODE wants to go is to begin to test these in cell models. So what kinds of models. So the challenges that exist for trying to do these kinds of things are that where to look. So if you delete an element what will be the effect of that change is it going to be on transcription initiation elongation splicing etc. So assays that are associated with, as I mentioned already, these kinds of functional events need to be created. The likelihood that these events will, you know, the deletion of a particular enhancer in one cell type will have a phenotype, it may be low because we are now beginning to realize there is a very high cellular and genomic sort of context for each of these elements. So deleting the element and looking in the appropriate biological setting for the requirement of that element is going to be key. So that choice of which regulatory element and which biological context is going to be critical especially considering we would like to do this in high throughput. And then there are other kinds of events, epigenetic events that might not be so obvious where the presence of the element as I already mentioned could be a priming event required later or a memory event and I will give an example of this. So one of the, so cellular context as an example, one of the, I will give an example of a Margroup, is we have been purifying cell populations from mouse frontal cortex using an affinity or a affinity tag, the nuclear membrane tag developed by Jeremy Nathan's group using the method Steve Hennikoff developed called intact, developed in a rapidopsis to purify different cell populations. So we've purified and looked at epigenetic marks in two different inhibitory cell populations and in excitatory cell populations. And it really clarifies what's going on relative to, for example, the whole cortex. So we're just looking at some, an example of the data here where you have whole cortex and you see some RNA expression of this particular GAT1 gene. If you then look at the three purified cell populations in replicate here, excitatory, PV inhibitory and VIP inhibitory neurons, you can see they're much higher expressed. When you look at the methylation patterns, you can see that the inhibitory cell populations have a real signature here in the DNA methylation pattern in CG and also in non-CG that don't, they really exist in the cortex or even purified all neurons, new N plus purified neurons. And you can see the same thing over here for highly specific VIP inhibitory expression and the correlation with the anti-methylation patterns of CG and non-CG context. So when you really identify, in fact, you can look at a much at looking at differentially methylated regions in these, if you just align them, you can see if you look at whole cortex and then you start to look at the sub-fractionated cell types, you can see patterns that are completely invisible in the, obviously, in the whole cortex or even in purified neuron populations. So cell context, specific epigenetic marks and really, for us, have put a shine of light on exactly what was happening in some of these that we could never get from any of the other less purified populations. And in fact, even you can see in these populations, there are of thousands of cells that there are sub-types in there when you actually go down and look at the reads. So also there are elements that indicate that there is a memory. So you can look, for example, I'll give another example from our lab that I don't have an example of prime, but there's a memory state where you can look at these regions that Bing Ren and our group defined as called DNA methylation valleys or DMVs. They're very large, 15 kilobase regions that are absent of DNA methylation and they don't always overlap with the CG islands. And so you'll have a large region that, in the adult, then collapses in terms of the length of the region that's not methylated. And you see, so there's hyper-methylation. And so that's something you say, well, that's quite interesting. What is that? And if you actually look then in the cell populations, I'll give an example over here for this particular transcription factor, this particular transcription factor shows this hyper-methylation pattern in the PV inhibitory cell and in both the CG and non-CG context. And if you look at the literature for that transcription factor, what you find is that actually the precursors of the PV cells that start in this medial ganglionic eminence and migrate out, they have to express that transcription factor for a brief period of time, otherwise they end up in the striatum. And so we believe this hyper-methylation is a signature of when the gene had to be expressed and then methyl transphase had access to that after it was silenced. And you can go through, in fact, all of these differential methylated valleys that have collapsed and find there's a very high enrichment for transcription factors that are involved in early development. And you can look at this list and go to the literature and find where there have been experiments that have sort of looked at the lineage tracing and you can see that there's a memory of the expression of many of these factors early in development. So we can see these events and sometimes they're predictive of what might happen to a sort of transcriptional anticipation or they're a memory of things that happened in the past. So connecting these elements with their cognate genes will require the development of novel assays of large scale. I mentioned some that already exist, but additional assays are going to be needed to get even higher resolution for elements that are closer to promoters. Systematic experimental perturbations are going to be needed to test the function of some of these elements, whether it's anticipation or you can go back and test some of these events earlier in development. These kinds of approaches are going to need more integrated, sort of integrating the function with these assays is going to require additional computational approaches which haven't been really developed for these high throughput deletion kinds of assays at this scale. And the challenges will obviously be how do you get this into or is it possible to develop assays to look at function at this scale. And we believe this type of effort of the development and implementation of these functional assays might be one area that encode could make an impact on, just as it has in the past on other areas. Some of the additional areas of interest are the really transforming now, the catalog of elements into an encyclopedia. And some of the ways to do that are going to require classifying these elements as enhancers, silencers or other, whatever that might be based on their function. So we want to know not only where the element is, but what it's doing and how it's doing it, to some extent, and identify all of these kinds of functional categories beyond what we have our prejudice about existing. So there may be elements, for example, that interact with other parts of the genome that is not just insist but also entran. They've been very difficult to necessarily identify and some of these kinds of approaches may allow you to do that. So that brings in the idea of really trying to interrogate the function of elements or the enhancers, silencers, elements that partition the genome, et cetera, by other kinds of high throughput assays. And some of these have already been developed and there's reference here. Others could be developed that could test some of these functions. And ultimately what we want to do is to understand this element functions in this context, what is the grammar of that? And this somewhat overlaps with the computational program that has been initiated by NHGRI, but these would be experimental tests that would allow further computational groups to access that data. That is to experimentally testing the grammar in different assay systems and then allowing the computational groups to also work on that data. And then finally, this is somewhat, probably will be more addressed by Rick and Mark, is beginning to apply this information to the biology of disease. And both by taking the variants that are known and beginning to relate them to both the biochemical activities and these new functional assays to come up with some level of confidence that a particular SNP is going to be, it's going to be useful to explore that further. So providing some high confidence estimates of the causality of a particular SNP based on these additional assay cell types as well as the functional assays that will be developed. So we think that ENCODA's position to make an enabling contribution in this area of functional genomics, that the high throughput approaches that for example of biochemical and otherwise that are being carried out will be complemented by new high throughput genome engineering approaches and perturbation systems. And that the importance is that the coordinated action of the consortium and the generation of this kind of data on a large scale will have an equal impact to the impact that, for example, Mike described for the last phases of ENCODE. So I'll stop there and take any questions that you might have. Yes, Eric? Joe, I enjoyed that. This is a council question, I think. You gave these layer one, two, three, four in a very logical order and a scientific progression. But now if you were forced to prioritize them of building the encyclopedia with the existing catalog, would that be more important than finding holes in the existing catalog and filling it with new data slash cell types? Which of those two do you think is the highest priority for NHGRI? Well, I don't know if I wanna, I put myself in conflict maybe if I answer that. So I think we haven't fully flushed out the catalog, that's clear. But we do need to begin to interpret what these elements are doing, right? And so I think that was probably one of the biggest criticisms that ENCODE got. It's not that it, I don't think it was ready for prime time basically to begin to do that. We need to find the elements and assess their function. So I think it has, those things have to go hand in hand. The challenge will be accessing the tissue some of it. So I think it can go on in parallel. In fact, I think different groups have different expertise. And I think that it doesn't have to be either or. I think that the technology groups working in hand in hand with some of the construction groups maybe in a closer way than has been done in the past might allow that to, to, to merge before the end of the project. Ewan. In, in the association of genes with their elements. I was sort of surprised, I was surprised not to see imaging. And was that very deliberate? Is that because it's happening somewhere else? Or do you feel that technology is not ready really for this, for this, this scale? I mean, was it just an emission? No, it wasn't an emission. It, there is, so the 4D nuclear will include that kind of imaging. I think it might be a little early days for the high throughput nature of the kinds of activities that ENCODE is going to carry out. It's possible that it could come along in the next year. But I haven't, I think it's, it's more of a development phase. So it could be a technology development. Several RFAs have gone out in this. I think, I think there was one that was part of road map that was for imaging of epigenetic variation during sort of a real time. I think it's one of the most exciting areas, frankly. But I'm not sure it's necessarily implementable in immediate, within the next year or so, the time, time frame that we're thinking about. Jay, you're. So, I was trying to understand the limitation about single cells, right? So your argument for stopping it, I don't remember what the lower bound was there, but was that with current single cell data, you get a sparse but rather random representation of what's going on within a single cell. For some of the assays, yes, others no. So it doesn't, I don't mean to say that it shouldn't be part of the project. I guess, I guess that if you want to have the kind of comprehensive set. So my point is that it's not a limitation, right? It's actually a strength because you can just aggregate cells that are of the same type and get the same data that you would have from each of the subtypes. Yeah. And, and, and nonetheless, also get the breakdown, right? Yeah, right. Well, depending on what you're, if you're going to recover 5% and then you have to do, you know, 20 cells. So sure, but that's fine, right? Because it's the same amount of sequencing. Yeah. It's, you sparsely cover each cell. And, and, well, if you want to attack the problem of, you know. I should let, if you'd like to speak here. Yeah, go ahead, sorry. I would just say that at the first level of approximation, that's exactly what happens in a bulk assay, except that you just aggregate the simulator. So at the very least, you would, in an ideal world, every read would be tagged for the cell it came from. You'll, some of the assays are right, 500 or 1,000, or they haven't reached 5,000. So you'd have to do 5,000 barcodes. If the sample prep, if the sample prep, if the sample prep cost is taken away, then sequencing-wise, it's exactly the same cost. Yeah, I agree. I'm not, I'm arguing against, against single cell. It's just that it isn't at the current cost of what these assays are, at least, current, currently. Yeah, I think it's, I think the critical thing is to understand it's not the sparsity that is the issue. The sparsity, it's the sample prep. Right, you, you have to combine, for some of these assays, 5,000 cells is needed, right, at this point, so. Right. Terrific. Can I, can I ask a technical question on the last? I mean, if sparsity, isn't sparsity an issue when the elements you're looking at are only a kb or even smaller, or could be smaller? I mean, I would think that sparsity is a very big issue. Let me, let me try and clarify. If you take an assay, even an incredibly noisy one at the single cell level, and you aggregate the signal, you get back the signal that you get from the bulk. Well, that means that the sparsity was there all along. It was there in the bulk assay as well. It's just hidden by the aggregation. So the question is, would you, do you aggregate post hoc or pre? That's all. But there are some biases, actually. If you look at the data, for example, for a single cell methylation data, it always, it always, it's biased towards specific regions over and over again in that cell. There's some bias in the bulk. No, no, you don't. When you have the, when you have the bulk, you get a much better representation. There's some stochastic events that happen in that early stage that you get the same thing over and over again. So it's not, it's not like you're just sub-sampling. It's your bias sampling in those, in those. Yeah, because you're, because the material, the bulk in preparing the material in, of a, it's the bias, yeah. Well, anyway, if you look at some of that data, you'll see what I mean. Yeah. Yes, I think the, the, the proposal is great. And, but I think it's, we all agree that it has to move from the correlation to functional validation. And you listed in the very beginning, a lot of technology development is needed. I think you didn't specify, but I feel like we need to develop heavily on epigenome editing, in addition to genome editing. Because you're going to correlate how the epigenome manipulation correlates into the relief function. And the second comment is, I think obviously we couldn't test all those elements. It's just impossible. So there is two questions. One is, how does those in vitro cell generated data going to really play the role in the physiological condition in vivo? Second is, how does that, how do we put the perspective of evolution to really study them, right? So, so my comment is to, to, to hit both questions is, have to use model organism, which is you can use evolution to prioritize. What is, I mean, it's very challenging bioinformatically, but if you can identify the top hits that's really well conserved, then that might be the problem. I didn't specify if this was all human or mouse or anything. I don't think I had. I love mouse, so that's what I was talking about. And human around stem cells. I think that's a too vast model. Our part of the project of encode is mouse. So I agree with you, but I, I did want to make this little organism agnostic about the epigenetic part. Yes, I agree. I work on epigenetics. Epigenetic editing will be key. And there have been some RFAs and maybe, and though there is some progress in that area as well, I didn't mean to eliminate that. I just thought for the purposes of most of the elements that have been interrogated so far, that they're linking them to the variants is, was a, is a priority. Yeah. So from my point of view, one of the biggest contributions of encode to date is actually the technology from the actual tech dev to more refined ideas of best practices and protocols and data analysis methods. And what you proposed here is in large, okay, let's look at all the technologies we already have and, and, and crank them. But I think the next. No, I, I'm sorry if I gave you that impression that I said new technologies, not necessarily. You elaborate on some ideas of what you think some of the new technologies next wave should do. No big, no big, why? That's for the community to decide. I, if I, if I knew that, I'd put it in a proposal. We are, there are many labs working on technologies that we haven't discussed here, but so I, I think I just put it under the category of new technology, send the, your best ideas. Yeah. Can, can I ask them in a flip side, which is also often very useful for engineers and for computational scientists, what are the biggest challenges that you would want to see solved? You know, if, if a fairy appeared and said, whichever, you can choose one or two technologies that would be the most impactful for you, which one would it be? Imaging activities in individual cells over the life of an organism. I buy into that. Okay. If there are no other questions, I guess next up.


Welcome everyone to the Andrew's talk. So the topic he's going to cover is the screenplay pattern. It's better interaction for better automation. So I think I will leave it Andrew. And hello everyone. Thank you for joining my talk today. My name is Andy Knight. I'm the Automation Panda. Today I'm gonna be talking about screenplay pattern, better interactions for better automation. As I said, my name is Andy. I'm Automation Panda. I am also a developer advocate at Apple Tools. If you don't know what Apple Tools is, they provide visual testing tools to help your apps look visually perfect. It's actually really cool stuff. If you wanna give it a try, register for free app tools to come on their website. We have SDKs for all the major languages, tools, frameworks. You can do Selenium Java, you can do Cypress, Playwright, what have you. My job is to stand between company and community to make sure you get the best out of your testing and to listen to your needs to bring back to help us do better things. At Apple Tools, I'm also a director of Test Automation University, which I'm hoping most of you have heard of. It's one of the best online resources for learning. We have about 70 courses online completely for free about all topics, testing and automation. Be sure to check it out if you haven't already. Now, more pertinent to today's talk, I am the lead developer for BOA Constrictor, which is the .NET screenplay pattern. My hope today is I'm going to show you why screenplay pattern is awesome. Screenplay pattern is a new way to automate interactions. It's not exactly new, I shouldn't call it new. It's been around for quite a few years now, but it's still new to a lot of folks. You may have heard of it, you may not have heard of it, but most people that I've met in our industry doing testing and automation haven't actually used screenplay before. Personally, I believe screenplay is a much better way to model interactions than the traditional page object model. Wow, I know that might sound scandalous, that's SeleniumConf, but I believe this. And my goal today is to convince you of that as well. So I'm going to try to do that in three parts. First, I'll cover problems with traditional ways of automating interactions. Second, I'll explain why screenplay pattern is a better way. And third, I'll show how to use screenplay pattern with BOA constructor, the C-sharp library that my friends and I had built. So let's define that big I word I keep tossing around. Interactions. Simply put, interactions are how users operate with software. For this talk, I'll focus primarily on web UI interactions like clicking buttons and scraping text. Interactions are indispensable to testing. The simple switch to define testing is interaction plus verification. Think about it, that's it. You do something and you make sure it works. Think about any functional test case you've ever written or executed. The test case was a step-by-step procedure in which each step had interactions and verifications. Here's an example of a basic search engine test for let's say DuckDuckGo. It's like Google, Yahoo, Bing, they're all about the same. The steps here are fairly straightforward. Opening the search engine requires navigation. Searching for a phrase requires entering keystrokes and clicking the search button. Verifying results requires scraping the page title, resulting from the new page. As you can see, interactions are everywhere. Unfortunately, our industry struggles to handle automated web UI interactions well. Even though most teams use Selenium WebDriver and their test automation code, every team seems to use it differently. There's lots of duplicate code of flakiness, too. But let's look at the ways many teams evolve their web driver-based interactions. We're gonna use C-Sharp and I'll continue to use this DuckDuckGo example. When teams first start writing test automation code using Selenium WebDriver, they frequently write raw calls. Anyone familiar with the WebDriver API should recognize these calls, even if you're not a C-Sharp programmer. WebDriver object is initialized using, let's say Chrome driver. First step to open the search engine calls driver.navigate.go2url to the DuckDuckGo website address. Second step, perform search by fetching web elements using... Oh, pardon me, sorry, it's early morning here. Pardon me. Second step, perform search by fetching web elements using driver.findElement. It uses locators or selectors. And then it calls methods like senkeys and click. Third step, uses assertions to verify the contents of the page title and the existence of the result links. Finally, at the end of the test, WebDriver quit, browser clean up. Like I said, these are all common WebDriver calls. Unfortunately, there's a big problem in this code. Race conditions. There are no less than three race conditions in this code which the automation does not wait for the page to be ready before making interactions. WebDriver doesn't automatically wait for elements to load or for titles to appear. Oh, pardon me again. Sorry. Waiting is a huge challenge for WebUI automation. And it's one of the reasons for quote unquote flaky tests. Now you could set an implicit wait that will make the calls wait until target elements appear. But they don't work for all cases such as the title and race condition number two. Explicit waits provide much more control over waiting timeout and conditions. They use a WebDriver wait object with a preset timeout value and they must be placed explicitly throughout the code. Here, they are placed in the three spots where race conditions could happen. Oh, sorry, pardon me. Each wait.until call takes in a function that returns true when the condition is satisfied. These waits are necessary, but they cause new problems. First, they cause duplicate code because WebElement locators are used multiple times. Notice how search form input homepage is called twice. Second, raw calls with explicit waits may code less intuitive. If I remove the comments from each paragraph of code, what's left is a wall of text. It's difficult to understand what this code does at a glance. To remedy these problems, most teams use the page object pattern, page object model. In the page object model, each page is modeled as a class with locator variables and interaction methods. So, a search page class could look like this. At the top, there could be a constant for the page URL and variables, and variables for the search input and search button locators. Notice how each has an intuitive name. Next, there could be a variable to hold the WebDriver reference. This reference would come via dependency injection through the constructor. The first method would be a load method that navigates the browser to the page's URL. And the second method would be a search method that waits for the elements to appear, enters the phrase into the input field, and clicks the search button. This page object class has a decent structure and a mild separation of concerns. Locators and interactions have meaningful names. Page objects require a few more lines of code than raw calls at first, but their parts can easily be reused. The original test steps can be rewritten using this search page class. Notice how much cleaner this new code looks. We can also rewrite the other steps using page objects as well. Unfortunately though, this isn't quite perfect. Page objects themselves solve for problems of duplication in their interaction methods. Suppose a page object needs a method to click an element. We already know the logic. Wait for the element to exist and then click it. What about clicking another element? The method here is essentially hard coded for only one button. A second click method is needed to click another button. The code for both methods is essentially the same. And the code would be the same for any other click method as well. This is copy pasta, and it happens all the time in page objects. I've seen page objects grow to be thousands of lines long due to duplicative methods like these. This point, some teams will say, wait a minute, you got more duplicate code? We can solve that with more object-oriented programming. And they'll create the infamous base page, a parent class for all other page object classes. The base page will have variables for the web driver and the weight objects. It'll also provide common interaction methods, such as this click method that can click any element. Extraction wins, right? Child pages will inherit everything from the base page. Child page interaction methods frequently just call base page methods. You've seen many teams stop here and say, child with dog, this is good enough. Unfortunately, this really isn't very good at all. The base page helps mitigate code duplication, but it doesn't solve its root cause. Page objects inherently combine two separate concerns, page structure and interactions. Interactions are often generic enough to be used on any web element. Coupling interaction code with specific locators or pages forces testers to add new page object methods for every type of interaction needed for an element. Every element can potentially need to be clicked, have as text grades, check if it's displayed or anything else. It's a lot of extra code that shouldn't be necessary. The base page also becomes very top-heavy as testers add more and more code to ship. More frustratingly, the page object code I showed is merely one type of implementation. What do your page objects look like? I bet dollars to donuts, they look different than mine. Page objects are completely free form. Every team implements them differently. There's no official version of the page object model. There's no conformity in its design. Even worse, within its design, there's almost no way for the pattern to enforce good practices. That's why people argue whether page object locators should be public or private. Page objects would be better described as a convention rather than a true design pattern. Mm-hmm. There must be a better way to handle interactions. Thankfully, there is. Let's take a closer look at how interactions happen. First, there's someone who initiates interactions. Usually, this is a user. They're the ones making the clicks and taking the scrapes and navigating the pages. Let's call them the actor. Second, there's the product under test. For our examples in this talk, that's a web app. It has pages with elements. Web page structure is modeled using locators to access page elements from the DOM. Keep in mind, the thing under test could be anything else, like a mobile app, a microservice, even a command line. Third, there are the interactions themselves. For web apps, they could be simple clicks and keystrokes, or they could be more complex interactions, like looking into the app, searching for a phrase. Each interaction will do the same type of operation on whatever kind, target, page, or element it is given. Finally, we have abilities. They enable actors to perform certain types of interactions. For example, browser interactions need a tool like Selenium WebDriver to make clicks and scrapes. Actors, abilities, and interactions are each different types of concerns. We could summarize their relationship in one line. Actors use abilities to perform interactions. Actors use abilities to perform interactions. This is the heart of the screenplay pattern. In page object convention, page objects become messy because concerns are all combined. Screenplay pattern separates concerns for maximal reusability and scalability. So, let's learn how to screenplay using Boa Constrictor. Boa Constrictor is an open-source, C-sharp implementation of the screenplay pattern that my former team and I developed while I was at Precision Lenders, a Q2 company. It is the cornerstone of Precision Lenders end-to-end test automation solution to this day. It can be used with any .NET test framework, like spec flow or end-unit. The product has a rich doc site hosted using GitHub Pages, which you can check out. The repository name is Q2ebanking.boaconstrictor. And the NuGet package name is boa.constrictor. Let's rewrite that doc.go-search test from before using Boa Constrictor. All the code I show on this talk is available in the Boa Constrictor library. You can even take the full tutorial to get hands-on with the code. To use Boa Constrictor, you'll need to install the Boa Constrictor, breast-sharp, and Selending and WebDriver NuGet packages. My example code here will also use Fluent Assertions and ChromeDriver, which are extras. Let's begin. The Actor is the entity that initiates interactions. All screenplay calls start with an Actor. Most test cases need only one Actor. The Actor class optionally takes two arguments. First, arguments and name, which can help describe who the Actor is. This name will appear in logged messages. Second argument is a Logger, which will send logged messages from screenplay calls to a target destination. Loggers must implement Boa Constrictor's iLogger interface. ConsoleLogger is a class that will log messages to the system console. You can define your own custom Loggers by implementing that iLogger interface. Abilities enable Actors to initiate interactions. For example, an Actor needs a Selending and WebDriver instance to click Elements on a web page. Read this new line in plain English. The Actor can browse the web with a new ChromeDriver. Boa Constrictor's Fluent-like syntax makes its call chains very readable. Actor.can adds an ability to an Actor. Browse the web is the ability that enables the Actor to perform web UI interactions. Browse the web.width provides the WebDriver object that the Actor would use, which in this case is a new ChromeDriver object. Boa Constrictor supports all browser types. All abilities must implement the iAbility interface. Actors can be given any number of abilities. Browse the web simply holds a reference to the WebDriver object. Web UI interactions will retrieve this WebDriver object from the Actor. Before the Actor can call any WebDriver-based interactions, the WebDriver pages under test need models. These models should be static classes that include locators for elements on the page and possibly page URLs, if appropriate. Page classes should only model structure. They should not include any interaction logic. Screenplay patterns separates the concern of page structure from interaction. That way, interactions can target any element, maximizing code reusability. Interactions like clicks and scrapes work the same regardless of the target element. Search page class has two members. First is URL, second is the locator for the search input. Locators have two parts. First, a plain language description that will be used for logging. Second, has a query or selector that's used to find the element on the page. Boa Constrictor uses Selenium WebDrivers by queries. For convenience, locators can be constructed using the statically imported L method. Let's move on to interactions. Screenplay pattern has two types of interactions. First is called a task. A task performs actions without returning a value. Think of it as like a void method. Examples of tasks include clicking element, refreshing a browser and loading a page. These interactions all do something rather than get something. Here, Boa Constrictor provides a task named navigate for loading webpages using a target URL. Read this line in plain English. The actor attempts to navigate to the URL for the search page. Again, Boa Constrictor's fluent like syntax is very readable. Clearly this line will load the doc.go search page. Actor.attempts2 is what calls the task. All tasks must implement the itask interface. When the actor calls attempts2 on a task, it calls the tasks perform as method. Navigate is the name of the task and .tourl provides the target URL. Navigate tasks perform as method, fetches the WebDriver object from the actor's ability and uses it to load the given URL. Search page.url comes from the search page we previously wrote. Putting the URL in the page class just makes it universally available. In a more serious project, you might want to read this in as some sort of input value to target whatever environment you're covering. And that's a task. Second type of interaction is called a question. Question returns an answer after performing actions. Samples of questions include getting an element's text, location, or appearance. Each of these interactions returns some sort of value. Right there, like the number seven here. Hmm. Excuse me. Bo constrictor provides a question named value attribute that gets the value of the text currently inside an input field. Read this line in plain English. The actor asking for the value attribute of the search page and search input element should be empty. Actor.asking4 is what calls the question. All questions must implement the iQuestion interface. On the actor calls asking for or the equivalent asks for method, he calls the questions request as method. Value attribute is the name of the question. And .of provides the target web elements locator. Value attributes request as method fetches the web driver object, waits for the target element to exist on the page and scrapes and returns its value attribute. Search page.searchInput comes from that search page class. And finally, once that value attribute is obtained, the test must make an assertion on it. Should be empty is a fluent assertion that verifies that search input field is empty when the page is first loaded. Test case next step is to enter a search phrase. Doing this requires two interactions. Typing the phrase into the search input and clicking the search button. However, since searching is such a common operation, we can create a custom interaction for search by composing the lower level interactions together. The search.go test takes in a search phrase and in this perform as method, it calls two other interactions. Send keys and click. Using one task to combine these lower level interactions makes the test code more readable and understandable. It also improves automation and usability. Read this line in plain English now. The actor attempts to search.go for Panda. That's concise and intuitive. The last test case step should verify that the result links appear after entering a search phrase. Unfortunately, the step has a race condition. The result page takes a few seconds to display result links. Automation must wait for those links to appear. Checking too early will make the test case fail. Bo constrictor makes waiting easy. Read this line in plain English. The actor waits until the appearance of result page links is equal to true. In simpler terms, wait until result links appear. Waits until is a special method. It will repeatedly call a question until the answer meets the given condition. For this step, the question is the appearance of the result links to the result page. Before links are loaded, this question will return false. Once links appear, it will return true. The condition for waiting for the answer is for the value to become true. Bo constrictor provides several conditions out of the box, such as equality, math operations, and string matching. You can also implement custom conditions by implementing the I-condition interface. Waiting is smart. It will repeatedly ask the question until the answer is met, and then it will move on. This makes waiting much more efficient than hard sleeps. The answer does not meet the condition within the timeout. Then the wait will raise an exception. Default times out to 30 seconds, but it can be overwritten. Running a Bo constrictor's web driver-based interactions already have waiting. Anything that uses a target element, like click, send keys, or text, will wait for the element to exist before attempting any operation. We saw this in some of the previous example code. However, there are times where explicit waits are needed. Interactions that query appearance or existence do not automatically wait. Final test step is to quit the browser. Bo constrictor has a quit web driver task for that. Remember, if you don't quit the browser, it might remain open and turn into a zombie. Always quit your browser. Furthermore, in whatever test framework you use, put the step to quit the browser in a clean up or tear down routine. So it's called even when the test fails. And there we have our completed test using Bo constrictor's screenplay powder. All the separated concerns come together beautifully to handle interactions in a much better way. Screenplay can also be used for more than web UI interactions. Bo constrictor has interactions for REST APIs using RESTsharp as well. Let's quickly step through a REST API test. Actors the same as before to call REST APIs. Active needs an ability named call REST API. It uses a RESTsharp REST client with a base URL. For this test, we'll use a public API called dog API, which returns random pictures of dogs, though I'm sure none of them are gonna be accused, my puppy. For this test, we'll use, sorry, one actor can have multiple abilities as long as each ability has a different type. So I could have an actor with a browser web ability as well as a call REST API ability. Bo constrictor uses RESTsharp's request, REST request objects directly, which specify resource path and HTTP method. To call REST API, Bo constrictor uses this call. The actor calls the REST request using that request object. We can then check response object for response code and other data. This test is quite basic, but Bo constrictor can also do some advanced tricks like downloading files, dumping responses, and automatically deserializing response bodies. REST API interactions may also be composed with web UI interactions, pretty cool. For example, you could perform login with REST API, grab the authentication cookie, dunk it in the browser, refresh, and you optimize login. Cool stuff like that. As we said before, the screenplay pattern can be summed up in one line. Actors use abilities to perform interactions. It's that simple. Actors use abilities to perform interactions. Those who like object-oriented programming, screenplay pattern is in a sense, a solid refactoring of the page object model. Solid refers to five design principles for maintainability and extensibility. I won't go into detail about each principle here because the information is a bit dense. But if you're interested, then snap a quick snapshot and check out all of these principles later. Wikipedia is a great source. You'll find the screenplay fits each one of these nicely. So why should you use the screenplay pattern over page object model or raw web drive calls? Here's a few key reasons. First, screenplay pattern and specifically the Bo constrictor project provide rich, reusable, reliable interactions out of the box. Bo constrictor already has tasks and questions for every type of web driver-based interaction. And each one is battle-hardened and safe. Second, screenplay interactions are composable. Like we saw with search for a phrase, you can easily combine interactions. This makes coding easier to use and reuse and it avoids lots of duplication. Third, the screenplay pattern makes waiting easy using existing questions and conditions. Waiting is one of the toughest parts of black box automation. Fourth, screenplay calls are readable and understandable. They use a fluent-like syntax that reads more like prose than code. And finally, screenplay pattern at its core is a design pattern for any type of interaction. In this talk, I showed how to use it for web UI interactions. But the screenplay pattern could also be used for mobile, SAPI, and other platforms. You can make your own interactions too. Overall, screenplay pattern provides better interactions for better automation. That's the point. This isn't just another Selenium web driver wrapper. It's not just a new spin-on-page objects. Screenplay is a great way to exercise any feature behaviors under test. And as we saw before, it's not that complicated. Actors use abilities to perform interactions. That's it. The programming behind it just has some nifty dependency injection. If you'd like to start using the screenplay pattern for your test automation, there's a few ways to get started. If you're in C-sharp, use Boa Constrictor. The library I just showed you. If you're in Java or JavaScripts, you've got Serenity BDD, which is a mature, complete test automation framework that includes screenplay pattern. In fact, Serenity BDD greatly influenced Boa Constrictor. But Boa Constrictor is not Serenity BDD for .NET. They're two entirely separate projects. Instead, Boa Constrictor aims to be a simpler, standalone implementation of screenplay. If you're programming in Python, I got great news for you. I just released a package called Screenflow, all-overcase. Python's screenplay package is a bare-bones implementation of the core pattern. It's something I've been working on all the side. I've actually used it with PlayWrite, and I have an example out there. So if you're interested in that, let me know. And I'd love help making that project more mature. And if none of these options suit you, you could create your own. Screenplay pattern does require a bit of boilerplate code, but it's worthwhile in the end. You can always reference code from Boa Constrictor and Serenity BDD. If you want to learn more, visit our docs. It provides thorough information about projects and about screenplay in general. I recommend taking that hands-on tutorial I mentioned so you can develop a test automation project yourself with Boa Constrictor. That tutorial covers both WebUI and REST API interactions. And since Boa Constrictor is open source, we'd love for you to contribute. So thank you again so much for taking the time, this morning, evening, afternoon, wherever you are in the world to learn more about screenplay. Again, my name is Andy Knight. You can call me Pandy for short. I'm the Automation Panda. Hit me up on Twitter at AutomationPanda. Check out my blog, AutomationPanda.com. I'm developer, advocate at Apple Tools and director of Test Automation University. I would love for you to start doing screenplay and reach out if you'd love to join the Boa Constrictor project. Thank you so much and we'll now move on to Q&A. Hello, thank you very much, Andy. I think it was very, very detailed and insightful talk. So I hope everyone enjoys.  He has done a great effort in doing the presentations and explanations. So now we have got like couple of minutes before we finish. So we have got Q&A session now. So if any questions, so please type it into Q&A chat box right now so we will deal on the stage right now. So Andy, there are three questions. So let me read the questions. So can we directly use the same actor to interact with both UI and API or we need two different actors? That is a fantastic question. You only need one actor. The whole purpose of screenplay is extensibility. It's the idea that you can add abilities and interactions as you need it without shoving everything into one class or one file. So you can say actor can browse the web and then the same actor can call REST API. You can even make other abilities. In my previous project, we had abilities, things like actor can read inputs, actor can read config. And so one actor can have multiple abilities. It's really nice that way. Okay, I hope it answers the questions. Another one is does it support Selenium 3 or we need to use Selenium 4? So Bow Constrictor is set to use Selenium 4. And the reason for that is a very pesky bug that we discovered in .NET framework, I think it was 4.7 under Selenium 3. So using Bow Constrictor, I should say it was not a Bow Constrictor thing, using Selenium 3 in .NET, if you were doing it at scale, it would eventually exhaust certain numbers of ports on your machine more rapidly than it should. But when we updated to Selenium 4, that problem went away. So hence, Bow Constrictor is set to use Selenium 4. Okay, I think I hope that answers the questions. So another one is how can we achieve this in Java? Great question. If you want to do screenplay in Java, right now, your primary option is Serenity BDD. That's the biggest implementation I know about in Java. I know a lot of people may not want to do that because Serenity BDD is a full framework and not just a standalone screenplay implementation. There's another guy out there. I forget his name. I wanna say it's Michael Kurtz. I'd have to look it up. There's some guy out there. I think he's from Europe. Who recently released his own tiny version of a screenplay pattern in Java. And I can't remember what it was called. Gosh, I'd have to look that up and share later. But he made like a little toy example. Maybe it's a little more than a toy. But he made like a small screenplay-ish implementation in Java. It's different from Serenity. It's different from Bow Constrictor. But you can look that one up too. I don't know how actively he's maintaining it. I got the, like, I shouldn't say anymore because I'm not very familiar with the project. I think he started it and tried it and kept going with it. And I think he's still working on it. I'm not exactly sure. I'm sorry. It's okay. I think that's the three questions were posted. So guys, if you, yeah, I think another one coming up. Does it support mobile app? So great question. Bow Constrictor currently does not have any out-of-the-box mobile interactions. That does not mean that screenplay or Bow Constrictor can't be used with mobile. You can make your own interactions for mobile. And so if that's something that you're interested in, I would love to chat with you because I would love to add, say, apiome interactions to Bow Constrictor. Okay. I hope that answers the questions, Charlie. Thank you very much, everyone. We are all signing off here and goodbye and good day.