I constantly apply to speak at Boston meetups and conferences world wide. Sometimes I get accepted. Here is my current list of proposals for reference. If you would like me to speak about these topics, get in touch. You can find my slides at slides.com/bahmutov and videos from previous speaking engagements at glebbahmutov.com/videos.html. Some presentations have links to slides and videos from conferences.
- Cycle.js: get in the loop
- It's not your parents' HTTP
- Hyped about Hyperapp
- Which web framework should I learn next?
- Semantic release
- Self-improving software
- What did we just test?
- Web application profiling using code snippets
- Workers of the world, unite!
- Alternative - only the ServiceWorker focused
- Browser is the new server
- How do you deal with runtime errors?
- Promises, promises, promises
- Remove the boilerplate
- Replacing built-in Node require
- Porting a cross-platform application to Windows
- AngularJS presentations
- Software Engineering presentations
- JSON schemas are your true testing friend
- Explain with examples, without writing any
- Building an orchestra of rock stars
- My ultimate "code quality as a service" proposal
- Think inside the box
- I see your point but ...
- Everything I know about writing quality software
- Shapes of development
- Snapshot testing
- Effective End to End Testing
- Testing across boundaries
- Будущие технологии тестирования: обзор
I am going to cover the following topics:
- how new features are added to the language
- main tools for testing, linting and bundling code
Previously shown to great acclaim at the following conferences
Cycle.js: get in the loop
An introduction to the Cycle.js: a modern functional reactive framework. Cycle.js breaks with the existing Model-View-Controller approach, instead focusing on making the data flow inside your application as clear as possible. All external interactions: the browser, the server API calls, the real time feeds are modeled as input and output reactive streams, making your own application code pure from side effects. Programming with Cycle is very different from using any other library for web development; attend this presentation to find out what makes Cycle.js so special.
- FrontEnd Camp NYC 2016 slides
It's not your parents' HTTP
The Internet of simple textual requests and responses is done. Finished. Obsolete. The modern web is a web of binary, persistent connections like WebSockets, WebRTC, HTTP/2 and QUIC. Today's Internet is a strange place where things are received before they are requested (Server Push) and a web application work without Web (offline support with Service Worker)
I will start with the history of HTTP, and how it changes from 0.9 to 1.0 and to 1.1. I will explain the performance benefit of HTTP/2, the state of support and a very interesting performance feature (Server Push). Then I will talk about real time systems that use Web Sockets for persistent data connection. Then I will talk about data synchronization solutions via in-browser database that can sync automatically. I will talk about offline support and instant web applications using ServiceWorker, and finally I will describe why HTTP/2 is going to be replaced by a protocol named QUIC based on UDP.
I have done this presentation several times, with different emphasis, and every time the audience loved the contrast between the original goals of HTTP 0.9 and how it is used now.
- NDC Oslo 2017 slides, video
- Amherst, MA Security meetup slides
- Waltham front end developers meetup slides
Hyped about Hyperapp
What is the smallest and purest front end framework out there? Did someone say Elm? I said smallest! The answer is Hyperapp - a really tiny, Elm-inspired pure functional web framework that combines the best features of today's hottest frameworks. It has built-in state management, pure functions, virtual DOM and still is easy to learn in 30 minutes.
- Boston Code Camp slides
Which web framework should I learn next?
Should I learn and use Angular 1, React, Angular 2, Ember or something else? What are the common features they all share? How are they different? Are there "better" frameworks that will be popular next year? I will show a couple of new approaches that should be part of any future-proof framework: reactive streams for managing the data flow, virtual DOM abstractions for speed, testability and performance tools built right into the framework. The presentation might be controversial, but the struggle to pick "the next best thing" is very real.
First, I will talk how unproductive are arguments "framework X vs Y". Then I will talk about features that are only now appearing in the web frameworks:
- DOM abstractions for performance reasons (moving virtual DOM computation into separate thread using WebWorkers)
- Modular design for smaller size (we can start small, or we can cut a large bundle)
- Hydration using ServiceWorker to speed up the startup times
- Offline support
- Universal rendering
- Reactive streams as first class objects
- Functional purity
- Real time support instead of "turn-based" abstraction
From another angle this presentation can be titled "My journey from MVC to FRP". Based on the personal experience, we have discovered many common problems the modern frameworks do not solve yet. Solving offline for example, requires dramatically rethinking the web application's architecture. I hope the redesign can happen soon, because the real world's needs demand the features from the above list!
You software does not have to be hopelessly behind in its dependencies.
You can automatically upgrade dependencies for an individual project, or a collection of projects. You can even estimate if a particular update is likely to succeed based on global stats. If upgrading your dependencies can be automated, why not streamline publishing new versions of our module? It is very easy using the existing semantic release tools.
Everyone argues about semantic versioning, modular architecture and large repos vs large number of dependencies. The tools I will show make the highly modular development possible. I have described a lot of ideas in a series of blog posts
I wrote the Node tools that allow splitting the project into lots of focused small modules, without increasing the effort that goes into keeping all the pieces working together. The tools are all open source:
- changed-log for seeing commit messages between any two releases
- next-update for upgrading an individual project
- next-updater for upgrading and publishing multiple projects
- next-update-stats keeps anonymous stats across multiple projects, see http://next-update.herokuapp.com
- dont-break tests projects depending on your module to ensure a safe release
is a plugin for
semantic-releasepipeline to use
dont-breakmodule before automatic publishing to NPM registry.
- next-ver is local semantic version update tool.
- version-remix is a work in progress that allows combinatorial explosion of published versions by releasing every permutation of features.
- NodeWeek 2017 slides
- ConFoo CA 2017 slides
- FrontEnd Camp NYC 2015 slides
- NodeJS Meetup NYC 2015 slides
/dev/summerCambridge, UK 2015 slides
What did we just test?
Use advanced code coverage techniques to better target the testing effort.
Code coverage tools are extremely useful, yet they do not show what the final coverage looks like. In the most development setups, the individual commits are cherry picked from the development to the staging to the production branch. The final coverage might be very different after some updates are transferred, merged. Add to this the fact that the manual feature testing is not included in the coverage information, and the metrics become useless.
I will show several tools that enhance the code coverage computed from unit tests.
First, there is a code coverage proxy
was-tested that I wrote.
It collects code coverage information during end 2 end feature testing, usually performed by the QA people.
This is extremely valuable, because most of the front-end code is extremely time consuming
to test using automated tests.
Second, I wrote tested-commits tool that takes any code coverage information and splits it back to coverage by an individual commit. Thus we can track how much we have tested each feature / bug fix that merged and moved around the branches.
Third, one can make any Node server a live source of real-time coverage events! Then just sit back and receive a stream of "line K covered" events.
Taken together, we can reliably speak about each feature tested at 90% before being deployed to production, even if the testing is manual.
Testing is hard. Unit testing with code coverage has recently become wide spread, while achieving code coverage for live website testing with actual users has not been practiced. I wrote tools to collect the code coverage on the fly (see blog post http://glebbahmutov.com/blog/code-coverage-proxy/) and to split any code coverage information into individual commits (read the blog post http://glebbahmutov.com/blog/code-coverage-by-commit/). These two pieces play nicely with existing unit test coverage tools (like istanbul), and solve huge quality problem in the modern web applications.
Web application profiling using code snippets
Find bottlenecks in live production code instead of running microbenchmarks.
Using code snippets we can start CPU, timeline and memory profilers, get very accurate information about any performance measurement, and quickly find the application's bottlenecks. We can even auto update locally stored code snippets using a code snippet!
In this presentation I will go through a typical web application, using different code snippets to measure and locate bottlenecks. Any developer trying to make a page faster would benefit from knowing about code snippets.
See blog post http://glebbahmutov.com/blog/performance-profiling-using-devtools-code-snippets/ where I walk through a typical web application step through step, finding bottlenecks using code snippets and then fixing them one by one.
The web performance is certainly an important topic these days. The code snippets allow accurate and quick profiling. My github repo with code snippets https://github.com/bahmutov/code-snippets has become my most starred project overnight.
Workers of the world, unite!
WebWorkers have been very useful for performing computation-intensive tasks in parallel, preventing browser lockup. Recently a new beast has appeared: the ServiceWorker. I will show how to use both WebWorkers and a ServiceWorker to add new features to the web development: rendering HTML from data without blocking the main thread, supporting offline mode, computation-intensive tasks.
I used a WebWorker to run Angular app in a WebWorker for speed, while using a ServiceWorker to have a flexible HTTP interception to provide exploratory testing at run time, see service-turtle. I also used ServiceWorker to make web application instant - appear inside the browser with no flashing or delay, see the blog post Instant Web Application. Finally, we can marry the two technologies: server-side rendering and the browser. I have been able to port the entire ExpressJS server to run inside the ServiceWorker, producing fast, "static" web applications, described in Run Express server in your browser.
Alternative - only the ServiceWorker focused
WebWorkers have been very useful for performing computationally intensive tasks in parallel, preventing browser lockup. Recently a new beast has appeared: the ServiceWorker. Most examples show this technology used to provide powerful offline support and smart caching, but we can do much more; achieving things that were considered impossible, like zero flicker instant web application startup.
I will show how to use ServiceWorker to implement what used to be considered impossible features
- Make any web application appear instantly in the browser (zero flicker)
- Run the most popular NodeJs server ExpressJS completely inside your browser
- Transpile the code on the fly precisely targeting the client environment
Browser is the new server
I have implemented several unusual hybrids of server and browser in these projects
- Run Express server in your browser
- Transpile missing features in the browser using babel-service
- procedural (imperative) style
- lazy evaluation
- immutable data
- async processing using promises
- async processing using event emitters
- advanced topics: transducers and streams
- reactive programming using event streams
Any team looking to improve its code should attend this presentation. Making a single leap from object-oriented approach to reactive programming is too difficult, but you can make it step by step.
This has been a very productive shift for me personally and for my team at Kensho. We are slowly moving away from procedural style and are currently at functional / promises steps. Our code became smaller, easier to test and understand.
These blog posts show the content I would like to present:
I have spoken about this topic at several conferences, always provokes a lot of discussion and many interesting responses. A few videos of me speaking are available http://glebbahmutov.com/videos.html and the slides are available at https://slides.com/bahmutov
- O'Reilly OSCON 2016 slides video
- Boston CodeCamp 2015 slides
- FrontEnd Camp, NYC 2015 slides
- ScotlandJS 2015 slides
- MountainWestJS, Utah 2015 slides
- LambdaDays, Krakow, Poland 2015 slides
How do you deal with runtime errors?
My main tools to guarantee good quality are:
- real-time error monitoring and crash reporting
- defensive and even paranoid programming style
- using lazy assertions
- exploratory testing to trigger bad server responses and see how the program deals with them
- best programming practices for ensuring errors do not silently disappear (cough Promises)
- snapshot and schema testing
Anyone tired of deploying websites only to see them break apart, or exhausted from banging on the app before deployment should attend this presentation.
Finally, the top jewel of our web applications is how robustly we handle errors (like bad server data). We can actually confirm that our error handling logic works using 3 different types of live server request intercept and mocking - read http://glebbahmutov.com/blog/robustness-testing-using-proxies/ how we do this.
Promises, promises, promises
Promises cut through the callback hell. Yet, they have their own quirks. In this talk I will show how to properly terminate promise chain in order to avoid silent errors; how to chain multiple steps together; how to tap into the chain for debugging; how to generate success vs error paths; how to add timeouts; how to generate and cache resources using promises.
- mocking server responses in live AngularJs application without any external tools
- patching Node system require function to make it more powerful
- testing functions for side-effects (purity test)
Think your function is safe inside a closure because no one can call it with unexpected arguments? Think again! I will show is how to compromise functions private to closures via references to the returned partially applied functions.
I described the "unapply attack" in this detailed blog post: http://glebbahmutov.com/blog/unapply-attack/ This is the current ES5 running in the strict mode. Without strict mode, all sorts of crazy things are possible, like changing the passed arguments inside the function, see http://glebbahmutov.com/blog/changing-the-function-arguments-trick/
- ManhattanJS meetup 2015 slides
Remove the boilerplate
- callbacks and pyramids of doom
- extra functions just to massage the arguments
- wrapper functions
- manual iterations
- special emphasis on removing boilerplate code from the unit tests
In each instance there will be a lot less code, but it will be more robust, manageable and simpler to reason about and test.
- Remove boilerplate from promise chains
- Less boilerplate in express app
- Testing without matchers
- From callbacks to Tasks
You can find all my blog posts that deal with removing boilerplate under the tag
- ConFoo CA 2017 slides
- Boston Code Camp 2016 slides
- NationJS Node Day 2016 slides video
- NodeJS Italy 2015 slides
Replacing built-in Node require
require method that loads source files, compiles and caches them is ok, but could be
made a lot more powerful. Luckily one can replace the built-in
require in user space without
much effort. In this presentation I will show how to
- use your own
requireversion with extra features, like cache busting and passing extra variables or loaded code transformation.
- speed up application startup by 25% with a single require include to avoid path hunting.
- quickly unit test most private functions and variables.
- related: secure the Node server by making the
- related: make loaded code a source of real-time code coverage events.
- really-need is a powerful
- cache-require-paths speeds up application startup times by 25% by caching filename resolutions to avoid path hunting.
- describe-it gives you access to any private function, functional expression and most variables without modifying the source code.
Porting a cross-platform application to Windows
Running an Electron application on Windows should be easy, right? Well, yes and no. In this talk I will describe the reality of building and releasing an end to end testing tool Cypress (OSS, MIT licensed, based on Electron application) on Windows platform. In the end, we were successful, but there were surprises along the road.
Secure your Angular applications
What do Chrome extensions written in Angular and secure websites have in common? They take Content Security Policy seriously! In this presentation I will show
- how bad things happen to good people
- how to switch from chasing the bad guys to protecting yourself
- how to secure your web application against cross-site scripting attacks
- AngularConnect, UK 2016 slides
Improving Angular application performance
Once your Angular application has the features you need, the next step is usually focused on improving its performance. The initial load time, responsiveness to user's commands - the application has to execute quickly in order to be useful. Is Angular framework fast or slow? I argue that is very fast, but requires knowing how to measure and optimize the right bottlenecks. In this example I will show multiple possible performance traps
- Measuring idle digest cycle time
- Simplifying and caching expression and filter results
- Removing double data binding
- In-code markup generation
- Quick above the fold markup generation
- Splitting large model / DOM update job into batches
- Offloading computation to a web worker
- Measuring and optimizing memory allocation
- On-demand computation
- Minimizing data attached to the scopes
- Limiting digest cycle to part of the application
- Keeping only visible parts of the application in the DOM
Anyone who needs to speed up Angular application should attend this presentation.
I have been working on Angular application performance problems recently, making our code faster. In the process I kept updating the blog post http://glebbahmutov.com/blog/improving-angular-web-app-performance-example/ with new findings. This blog post became very popular, if you google "angular performance" it usually comes up in the first 3 results. Today many people argue for / against Angular compared to other frameworks, it is important to know the Angular-specific common performance bottlenecks and how to avoid them.
Unit testing AngularJS
Writing unit tests is a time-consuming chore; but it is necessary before we can fix bugs or develop new features. Testing AngularJS code in particular requires a lot of boilerplate. In this presentation I will show a simple helper library can remove all the extra code and allow to unit test code in seconds.
Take a look at ng-describe - it provides a single
ngDescribe that is a BDD wrapper specific to the Angular framework.
ngDescribe makes injecting specific services to be tested very quick and intuitive.
It also provides advanced features, like mocking services and HTTP responses. As I describe
testing different Angular aspects; from simple values to custom directives; I will point
ngDescribe has a user-friendly API.
ng-describe in your tool belt, there is no more excuse no to test your code.
A simple checklist to follow
Alternative title: A checklist for your Node project.
I want my NPM module to be useful, robust, and well-documented. I want it to stand out from the 100s of the modules that do a similar thing. Here is my recipe for a module that everyone can rely on: a simple checklist. Rather than forcing everyone to do the same, the checklist only reminds me to do unit testing, publish smaller module, have good API examples, and lots of other useful things.
I have published hundreds of modules on NPM. While not as prolific as some NodeJS superstars, I know that others can reuse my work, and it is simple for me to implement a new feature when needed. My development and roadmap for each module is open - it is in a simple checklist I share freely at bahmutov/npm-module-checklist.
I will go through main items in my list; why a particular TODO item is important and the main tools that help me to mark it done.
Securing the front end, from a Node server
As a bonus I will show another project that can prevent sensitive information leaking to GitHub and NPM.
- How bad things can happen when the server-side rendering or injection is combined with web application templating, see these slides for the full example.
Software Engineering presentations
JSON schemas are your true testing friend
In our company we have a lot of data flowing from the user’s applications (and we are backwards compatible) to the API, then this data is displayed in the web dashboard. How do we avoid accidentally breaking API contracts, while adding new features? We have started using json-schema convention and wrote a few tools around it to lock down our API protocols. Now we have full confidence in our tests, and major refactorings and releases happen without hiccups. Bonus: our tests are realistic, elegant and easy to understand.
At Cypress we have 3 large pieces of software:
The Cypress Test Runner, an Electron desktop application. The API which receives test results from the Test Runner when running
cypress run --record The Cypress Dashboard Service, a web application that shows test results to users. When we were planning version 3 of the Cypress Test Runner, we needed to make sure big changes to the way the Test Runner processes test runs did not break anything these changes were especially important as we were preparing to introduce automatic test load balancing. Not only the Test Runner had to change, but the API had to introduce new features while supporting both existing versions of the Test Runner and the new v3. The changes also would affect the Cypress Dashboard.
In short - we had a huge amount of work on our hands; and this work had to be backwards compatible.
The solution we came up with to avoid accidentally breaking our clients (both the Test Runner and the Dashboard could be called our API’s clients) was easy to understand and use. It solved the version problem, made testing super simple and made self-documenting code a reality. This presentations shows our solution by going through an API and showing what we did at each step.
- Boston JS meetup August 2018 slides
Explain with examples, without writing any
Humans learn best by example; good technical docs use lots of them. Yet all modern documentation tools (think jsdoc) making writing correct examples and maintaining them a chore. There is no tool support for syntax highlighting, or even guarantee that an example is correct or up to date.
On the other hand, solid software projects have lots of well tested, up to date examples. We call them unit tests!
In this presentation I will show how to take the unit tests and transform into syntax-agnostic human-friendly examples to be plugged into your docs. Documenting your API will never be the same - it will be a simple and pleasant experience. One can even target other types of documentation: my blog posts have examples that are generated from unit tests, thus sparing me the embarrassment of having a broken source fragment.
- CodeMotion Berlin 2016 slides
Building an orchestra of rock stars
Our startup Kensho has achieved a lot in less than 2 years: signing up huge corporate clients, being used by CNBC on the air every day and even changing how the financial research is done. All these things were done with a small number of exceptionally productive engineers. In this presentation I will go over our two strengths: a development approach we call Agile+ and unorthodox approach to hiring new engineers.
Agile+ means we prototype quickly a feature but always invest time to refactor if it is to stay; no technical debt accumulation long term. Our hiring focuses on people with experience and students still in college; then we train the rock stars out of them.
Finally I will talk about the dark area in software industry: handling employees who quit, and how we are trying to change this experience at Kensho.
I have delivered this presentation at the Great League of Engineers event in Boston where we talked about what makes some teams very productive. You can find my slides at http://slides.com/bahmutov/rockstars and notes from the event at http://glebbahmutov.com/blog/great-league-of-engineers/
- Great League of Engineers, Boston slides
My ultimate "code quality as a service" proposal
Continuous build services (like TravisCI) became a must-have tool for any serious project. The setup is super quick and checking every pushed commit, or Github pull request is very valuable for keeping the project build green. Recently, several other "code metric as a service" resources became popular: test code coverage and static code analysis. What if I could design my own "code quality as a service"? What could it do? How would it present its results? Can it help us solve the technical debt accumulation problem?
More details available in Code quality as a service blog post.
Think inside the box
There are four operations "Ops" things that I am excited about today: Docker, Kubernetes, Dokku and Zeit. All make my life as a developer a lot simpler, they change the way I test software and they blur the line between the local and the production environments. Enterprises already use the first two, while every developer should use all four tools.
It used to be hard to actually run code in production. I needed to rent a rack server from a company, login into the machine, set it up, then periodically deploy new application version. Deploying often meant overriding the existing running application, taking a server offline. Long, cumbersome, and error prone. No wonder we did deploys once a month! Luckily there are 4 things that recently revolutionized the way I deploy and run code: Docker, Dokku, Kubernetes and Zeit Now.
Here are the 4 things that completely changed the way I, a developer, view code deployment and running the production servers.
- Docker allows me to run my code in the same environment as the server.
- Kubernetes is managing multiple docker boxes as one.
- Dokku is open source platform to run docker containers that is perfect for personal projects.
- Zeit.co makes code deploys almost instant, and more importantly the deploys are immutable.
I see your point but ...
- test-driven development vs end to end tests
- stubs and mocks
- cross-browser testing
- code and data coverage
- picking the right test framework and snapshot testing
- legacy browser environment support
- crash reporting and performance monitoring
- earning leaving by writing OSS testing tools
We will have a dialog and an argument about the means, but our goal is a common one: making the software running the world more reliable.
Everything I know about writing quality software
In this presentation I will show all the tools I use to write software that does not break but keeps the users happy. Static types, exception monitoring, unit tests with snapshots, randomized testing, code and data coverage, code complexity metrics and awesome end to end testing tools - the list is long and keeps on growing! The techniques I plan to show are applicable to every framework and environment.
A preview talk has been given and warmly received by the MIT web development class 6.148 of 2017, see the slides here. But the universe of tools keeps growing and we can adapt tools that came since (like snapshot / schema testing). For more details, see my blog posts on testing.
Shapes of development
A geometric shape is simple to remember and visualize concept, familiar to any child. In software development we have a few concepts with associated shapes: agile is shown as a spiral curve, waterfall as, well, a waterfall, etc. In this presentation I will show the shapes that describe other modern development approaches and architectural styles.
In this presentation I will go through a list of concepts, each concept closely matching a geometric shape. While the list is long, here are the main shapes:
- Artifact repositories decouple software development steps, and can be visualized like large warehouses storing versioned code, ready to be "shipped" to be assembled into a new application.
- Software isolation using Docker can be drawn as a box. Multiple boxes can be stacked and deployed together in a cluster. Closely related to are immutable deploys that always build a new set of boxes, rather than modifying the existing one.
- A reactive system useful for modeling modern user interfaces can be described as a directed acyclical graph (the user is the missing link that would close the cycle)
- A typical developer's expertise is a T-shaped figure, and often a little investment in related vertical "bars" can be extremely beneficial. In particular, the knowledge to install a library or an application can be modeled as a pyramid. By making the pyramid's layers thinner we can achieve reusable software.
A right abstraction goes a long way in making a concept simple to understand. This presentation shows the shapes that helped me be more productive and explain my work to others.
- reusable software with semantic versioning
- immutable deployment pipelines
- functional reactive programming
- developer's skills and learning
- Boston Node meetup slides
There are a few web frameworks that are all the rage right now: React, VueJs, but which frameworks are going to be HOT tomorrow and why? I will talk about functional reactive web applications you can write today, and why they are going to rock tomorrow. We are going to touch upon offline applications (using ServiceWorkers) and why some databases are better than others. Plus I will show how a testing trapezoid is going to save your career. Finally, we need to sit down to have a real talk about Dev Ops; if immutable data structures help you code better apps, then immutable artifacts and deploys are going to change your entire pipeline.
Snapshot Testing is a recent technique in unit testing and automated testing in general that's been gaining some traction, thanks to a new excellent test runner called Jest. I will show what snapshot testing is, how you could implement this tool yourself, and how to extend this approach to dynamic data with schema testing, and how to remove almost all boilerplate using data-driven testing.
Effective End to End Testing
Unit testing is hard and time consuming; and worse - the users and the customers do not care! They only want the features working in the production system, everything else is development overhead. If this is the case, how do we improve the web application quality? How do we catch the bugs early? How can we test the deployed system effectively? And finally, how do we get rid of Selenium? This presentation tries to answer many of these questions in a web framework agnostic way.
As a VP of Engineering at Cypress.io I have front seat to end to end testing for web applications. Currently we are open sourcing our complete testing tool; it is a fast and powerful replacement for Selenium and every other similar tool. In this talk I will show how one can quickly test all features of a modern web app. Cypress design and features were strongly influenced by the unit testing and modern snapshot testing technique and provide fast feedback, full access to the application and great developer experience. The goal of the project is to flip the testing pyramid and allow anyone to write A LOT of useful end-to-end tests really quickly.
Testing across boundaries
Developers like to test on their local machine. Then the code gets built by CI and things break - missing dependencies, mismatched configuration, different environment. I will show how we effectively test our code when it crosses such boundaries: local to CI, CI to staging, staging to production.
The ultimate "it works on my machine" only happens when the code runs on a different machine. I call these code transitions from local to CI, from CI to staging and from staging to production "crossing the boundary", and believe we must test our code every time a boundary is crossed. Yet we do not work very hard on making the code testable! Worse, we often allow using very different tools to monitor and test production versus CI. In this talk I will walk through a typical web application and all the places we can test it using the same tools, ensuring the bugs are caught early and the production works as expected.
Будущие технологии тестирования: обзор
- QAFest, Kiev, Ukraine 2016 slides