Max Guernsey, III

You’re a TypeScript developer for a large company that sells stock photography. You’re responsible for the service that ingests images, and it’s been having problems, despite successful unit testing. Working in IntelliJ WebStorm and the Nest framework, you’ll build an integration test that replicates an otherwise unreproducible problem. You’ll also mock an external service to address and prevent problems related to external dependencies. To address problems that only occur when two services are combined, you’ll use integration testing to connect and run the two services together. When you’ve completed this series, you’ll have an integration testing strategy that goes well beyond the capabilities of unit tests for ensuring the stability of your code.

You’re a TypeScript developer for a large company that sells stock photography. You’re responsible for the service that ingests images, and this service depends on another subservice: the pricing microservice. As proven by their individual unit tests, each service works as specified. But when the services are combined, new customers are locked into one pricing table—even those that should have access to pricing that fluctuates depending on factors like promotions, flash sales, and price-tuning. Working in IntelliJ WebStorm, you’ll solve this problem by writing an integration test that connects and runs the two services together, letting you reproduce the problem locally.

Ensure your system can accommodate even unstable dependency services. You’re a TypeScript developer for a large company that sells stock photography. You’re responsible for the service that ingests images. Unfortunately, the ingestion process is being negatively affected by a flaky external web service that the ingestion engine uses, and the problem is not reproducible in unit testing since there’s no connection to the external service at that time. Working in IntelliJ WebStorm, you’ll establish an in-memory HTTP service, configure it to simulate a dependency service, write a test to reproduce the error, and use the test to build robustness into your system.

Create an alarm system that warns you before your system breaks. You’re a TypeScript developer for a large company that sells stock photography. You’re responsible for the service that ingests images. A recent upgrade to the image-scaling library has caused a problem with the aspect ratio of thumbnail images. Working in IntelliJ WebStorm, you’ll build a layer of integration tests that replicates the problem and also tests the assumptions that your unit tests rely on. When you’re done, you’ll have an alarm system that warns you when the assumptions your unit tests rely on are no longer valid, preventing problems in the future.

You’re a TypeScript developer for a large company that sells stock photography. You’re responsible for the service that ingests images, and a recent database change has broken the service, despite successful unit testing. Working in IntelliJ WebStorm, you’ll build an integration test that replicates the problem, find the cause, fix the problem, and build the infrastructure to develop more integration tests in the future.

It’s a problem almost every developer will face in their career: inheriting an essential legacy library that’s full of bugs and has no automated tests to keep it running smoothly. In this liveProject series, you’ll step into the shoes of a TypeScript developer handling just such a codebase for a stock image web application—one that will soon require significant changes to the library you maintain.

You’ll use Jest and IntelliJ WebStorm to write tests and refactor this buggy code into something that’s both usable and indefinitely maintainable. Each project focuses on a different approach or testing methodology that will be a useful addition to your testing toolbox.

As a TypeScript developer, you’ve recently created a high-quality test suite as part of your company’s goal of adding functionality to its system. Now, using test-driven development (TDD) techniques, it’s time to analyze new requirements, reconcile them with what is currently documented by your test suite, and use the test-first technique to ensure changes to your library are justified, specified, and protected by tests.

You're a TypeScript developer at an organization that sells stock photography products to the general public, as well as to news and other media markets. The company wants to add functionality to its system that maximizes the profitability of any given search. It’s up to you to improve the test suite by adding high-quality requirements-based tests. You’ll use mocks to isolate requirements, ensuring that each test focuses on a single behavior in your code. When you’re done, you’ll have a more resilient codebase.

The company you work for wants to improve its system by adding functionality that maximizes the profitability of any given search. As the resident TypeScript developer, your task is to apply a battery of tests to support changing the design of legacy code in preparation for adding this new functionality. You’ll refactor your production code based on advice from your architecture team. Thanks to a broad test suite, you’ll be able to change your design with no worries about accidentally breaking a required behavior. The result will be a system you can test with smaller, more meaningful tests and that easily withstands future requirement changes.

Your company sells stock photography products to the general public, as well as to news and other media markets. As the resident TypeScript developer, you’ve been tasked with maintaining and extending a class library for optimizing search results. You’ll set up tests to support refactoring of this legacy library, use “pinning tests” to extract a specification from the existing code, and generate a wide range of test coverage. You’ll learn to spot when and where to improve code maintainability, and set up mutation testing to ensure your tests catch unintended changes. By the end, you’ll have generated test coverage that supports refactoring, making future updates easy and painless.

You’re a TypeScript developer for a large company that sells stock photography products to the general public, as well as to news and other media markets. Your task is to find and fix some long-term bugs in a legacy library. You’ll write a test to characterize a bug in code that controls how certain assets are selected for a special display. After you’ve determined the source of the problem, you’ll modify the test, transforming it into a bug fix. Once you’ve squashed that bug, you’ll repeat the process to tackle two additional common bugs in TypeScript applications.

You’re a Java developer for a large company that sells stock photography. You’re responsible for the service that ingests images, and it’s been having problems, despite successful unit testing.

Working in IntelliJ IDEA and the Spring framework, you’ll build an integration test that replicates an otherwise unreproducible problem. You’ll also mock an external service to address and prevent problems related to external dependencies. Finally, you’ll use integration testing to connect and run two services together to address problems that only occur when they’re combined. When you’ve completed this series, you’ll have an integration testing strategy that goes well beyond the capabilities of unit tests for ensuring the stability of your code.

You’re a Java developer for a large company that sells stock photography. You’re responsible for the service that ingests images, and this service depends on another subservice: the pricing microservice. As proven by their individual unit tests, each service works as specified. But when the services are combined, new customers are being locked into one pricing table—even those that should have access to pricing that fluctuates depending on factors like promotions, flash sales, and price-tuning. Working in IntelliJ IDEA, you’ll solve this problem by writing an integration test that connects and runs the two services together, allowing you to reproduce the problem locally.

Ensure your system can accommodate even unstable dependency services. You’re a Java developer for a large company that sells stock photography. You’re responsible for the service that ingests images. Unfortunately, the ingestion process is being negatively affected by a flaky external web service that the ingestion engine uses, and the problem is not reproducible in unit testing since there’s no connection to the external service at that time. Working in IntelliJ IDEA, you’ll establish an in-memory HTTP service, configure it to simulate a dependency service, write a test to reproduce the error, and use the test to build robustness into your system.

Create an alarm system that warns you before your system breaks. You’re a Java developer for a large company that sells stock photography. You’re responsible for the service that ingests images. A recent upgrade to the image scaling library has caused a problem with the aspect ratio of thumbnail images. Working in IntelliJ IDEA, you’ll build a layer of integration tests that replicates the problem and also tests assumptions that your unit tests rely on. When you’re done, you’ll have an alarm system that warns you when the assumptions your unit tests rely on are no longer valid, preventing problems in the future.

You’re a Java developer for a large company that sells stock photography. You’re responsible for the service that ingests images, and a recent database change has broken the service, despite successful unit testing. Working in IntelliJ IDEA, you’ll build an integration test that replicates the problem, find the cause, fix the problem, and build the infrastructure to develop more integration tests in the future.

It’s a problem almost every developer will face in their career: inheriting an essential legacy library that’s full of bugs and has no automated tests to keep it running smoothly. In this liveProject series, you’ll step into the shoes of a Java developer handling just such a codebase for a stock image web application—one that will soon require significant changes to the library you maintain.

You’ll use JUnit 5 and IntelliJ IDEA to write tests and refactor this buggy code into something both usable and indefinitely maintainable. Each project is focused on a different approach or testing methodology to let you pick and choose which testing techniques to add to your toolbox.

In this liveProject, you’ll explore writing high-quality, requirements-based tests against code with a solid design.You will take great care to ensure that each test focuses on a single, isolated behavior within the code. To that end, you’ll use techniques such as mocking to isolate requirements from one another for the purpose of testing. The output of the project is a codebase with a far more resilient test suite that will be able to stand the test of time.

In this liveProject, you’ll write tests to drive changes in an existing codebase. You’ll analyze new requirements, reconcile them with what is currently documented by your test suite, and use the test-first technique to ensure new changes to your library are all justified, specified, and protected by tests.

In this liveProject, you’ll learn to use a battery of tests to support changing the design of some legacy code in preparation for adding new functionality. You’ll refactor your production code based on advice from your architecture team. Because you have a broad test suite, you will be able to change your design without fear of accidentally breaking a required behavior. The output will be a system that can more easily withstand incoming requirements changes and against which you can write smaller, more meaningful tests.

In this liveProject, you’ll set up tests to support refactoring of a legacy library. As you lack a written specification, you’ll use “pinning tests” to extract a specification from the existing code, and generate a wide range of test coverage. You’ll learn to spot when and where to improve code maintainability, and set up mutation testing to ensure your tests catch unintended changes.

In this liveProject, you’ll find and fix some long-term bugs in a legacy library. You’ll write a test to characterize a bug in how certain assets are selected for a special display, then modify the test to turn it into a bugfix. Once you’ve squashed that bug, you’ll repeat the process to tackle two more common bugs for Java applications.