api_weather

Gain insights into unit testing Elixir applications with ExUnit, explore advanced integration and E2E testing, and master OTP, Phoenix frameworks, API testing, and platform-specific refactoring.

testingElixir.tar.gz

First Test

SoggyWaffle-mix test

chapter2-RealExternalDependency - soggy_waffle_test

Chapter3- GenServer-Example

chapter1-isolating code 

chapter1-dependencyinjection -fine

Ch4-testing-ecto-schemas-

Ch4-testing-ecto-schemas--mix deps

Ch4-testing-ecto-schemas--Database tmux 2 shell makeup

Ch4-testing-ecto-schemas--Database tmux 2 shell window

Ch4-testing-ecto-schemas--Database tmux 2 shell databasetest

Ch4-testing-ecto-schemas--Database tmux 2 shell databasetest-copy

Ch6-testingPhoenix-error test

chapter2-RealExternalDependency - soggy_waffle_test-copy

Chapter3- GenServer-Example-copy

Ch6-testingPhoenix-error test-copy

Ch6-testingPhoenix-error test-copy-lbr

ch7-property-based-testing

Ch6-testingPhoenix-error test-copy-check

Ch6-testingPhoenix-error test-copy-happytest

Chapter3-edit

chapter1_l2

chapter1_l6

chapter1_l7

chapter1_l10

chapter1_l13

chapter1_l14

chapter2_l3

chapter2_l4

chapter2_l6

chapter2_l7

chapter2_l9

chapter2_l14

chapter2_l15

chapter2_l16

Ch4-testing-ecto-schemas--mix deps-refactor

Ch4-testing-ecto-schemas--mix deps-shared

chapter3_l4

chapter3_l5

chapter3_l6

chapter4_l3

chapter4_l4

chapter4_l5

chapter4_l6

chapter4_l7

test

chapter4_l11

chapter4_l12

chapter4_l13

chapter5_l3

chapter5_l4

chapter5_l5

chapter5_l6

chapter6_l4

chapter6_l5

chapter6_l6

chapter6_l7

chapter6_l9

chapter6_l10

chapter6_l11

chapter4_l13-copy

chapter6_l3

Ch6-testingPhoenix-error test-copywithMix

ch7-property-based-testing-copy

ch7_Introducing_stream_data

ch7_Writing Properties

ch7_Shrinking

ch7_Strategies

ch7_ Smoke

Chapter3- GenServer-isolating

Chapter3- Controlling

Chapter3- GenServer1

chapter4_l10

chapter6_l3-copy

ch7_ Properties

Testing is an essential part of the software development life cycle. A good automated testing suite streamlines feedback, allowing rapid creation and tight control over specific application components.

This course is a comprehensive introduction to testing Elixir applications with ExUnit. You’ll start with a review of unit testing principles before diving into writing tests with the ExUnit. You’ll build a comprehensive suite of unit tests before moving on to more advanced testing, including integration, end-to-end, and property-baste testing. In addition to the core Elixir environment, you’ll also develop tests for OTP, the Phoenix web framework, including JSON APIs and Ecto schematics. You’ll also explore refactoring for different platforms, server rendering, and design strategies.

By the end of this course, you’ll be an expert in unit testing Elixir applications with ExUnit and ready to build robust, performant applications using Phoenix.

Ensuring Elixir Application Performance with Testing and ExUnit


# Comparison with the test server method

This approach differs from a test server because it focuses less on asserting that the request is made correctly. The main goal is to behave exactly like the real third-party service without writing code to emulate that third-party service. The workflow is, in fact, simpler than the test server, in that we wrap our code with `use_cassette/2` and go on about our day.

However, cassettes present a similar problem to the test server: they can get out of sync with the actual API. The solution lies in keeping cassettes up-to-date.


## Keeping cassettes up-to-date

Compared to a test server, we adopt a much simpler approach to keep the cassette up to date. We only have to delete the stale cassette and rerun our tests. 

To further push the idea of keeping cassettes up to date, we can always force real requests when running tests in continuous integration (CI) server. This way, we’ll avoid making real HTTP requests when developing on our local machine, but the CI server (which usually runs much less frequently) will ensure that the cassettes haven’t gotten out-of-date.

>**Note:** This approach heavily depends on what requests the real API implies.

In the weather API example, making real requests to `/data/2.5/forecast` is feasible. If it’s only done in CI, then it’s unlikely that we’ll negatively affect our rate limiting.

In other cases, making requests might cost money or break things, so making real requests on every CI run might not be ideal. Furthermore, we usually want CI to be reproducible and consistent between runs, and depending on the availability of an external API might not be feasible.




## Favorite use case

Cassettes can be used as an external service that allow us to set up and tear down resources through its API.

For example, the weather API could expose endpoints to register and delete named queries. If we wanted to test that we can query the forecast through a named query, we could create the named query, test the appropriate functions, and delete the named query all in the same test. In this use case, the cassette merely becomes a cache of HTTP requests. Even when not using cassettes (such as in CI), the test would create and destroy all necessary resources to run the test, leaving the external service’s state unchanged.

## Never reuse cassettes!

If we have two tests that make the same request, we might be tempted to use the same cassette, but there’s a good chance that at some point, the request made in one of the two tests will change slightly, and then things won’t work anymore. 

If we use a different cassette in each test, we’re guaranteed not to mess things up in this regard.






Let's compare cassettes with the test server method and understand its usage.

Comparing Cassettes

Getting Started

Unit Tests

Integration and End-to-End Tests

Testing OTP

Testing Ecto Schemas

Testing Ecto Queries

Testing Phoenix

Property-Based Testing

Comparing Cassettes

Comparison with the test server method