chaotic_job 0.1.1 → 0.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: b82a52379f9efe41b3243e19904fa96e0cc8703bf813a42401b74128242ea6a2
-  data.tar.gz: b4979b0ba3ddec6e2c8ab680458853a7ffeda84e25af95e6858d16846f5d77b2
+  metadata.gz: 8241f1235f37ed46c1da18d53e18c6fce43fb5758273bb51dba8db332dddb5b6
+  data.tar.gz: fc86ee73cf18b16d6142f7111e5d1cfa446b46bfea2e1959eb7aa222a5bf42dd
 SHA512:
-  metadata.gz: 0f38bed8995ac63a1755dcb316c3886dcf32cb5fb953aec4d3be8ce4b3b7690c76febacc458fc05ca2e30ef8b67947a4b639f7035e8cea7aac84d59bd1da37a3
-  data.tar.gz: 616f9d8543fa39d00e30f82bd20edb22ddae4578f4c0e9a7557135b599002f9dbdc29a64bba6c25471a76f489004556745e3708310789d6f716fe9c879ccd2ff
+  metadata.gz: 7d32f1ab9748ea544d13c15692934634a6c3bcc01d602903e5e554abd229b7623a6a9aff111357031f474ec701fcd96131994604a121f9e55672eaed2616107b
+  data.tar.gz: c8ef73d8d07a091f59ebd1347ecc3f11fbd6ba6abc3eee218e251600ff156f748ec2a911d8108834cad96f9ce7ef59d1b3989606a27a827f1bb7bd93bfd9b062

data/CHANGELOG.md

@@ -1,5 +1,12 @@
 ## [Unreleased]
 
+## [0.2.0] - 2024-11-06
+
+- Update the `perform_all` helper method to `perform_all_jobs`
+- Update the `perform_all_before` helper method to `perform_all_jobs_before`
+- Update the `perform_all_after` helper method to `perform_all_jobs_after`
+- Update the `perform_all_within` helper method to `perform_all_jobs_within`
+
 ## [0.1.1] - 2024-11-06
 
 - Update `Journal` interface

data/README.md

@@ -10,7 +10,7 @@
 > [!TIP]
 > This gem helps you test that your Active Jobs are reliable and resilient to failures. If you want to more easily *build* reliable and resilient Active Jobs, check out the companion [Acidic Job](https://github.com/fractaledmind/acidic_job/tree/alpha-1.0) gem.
 
-`ChaoticJob` provides a set of tools to help you test the reliability and resilience of your Active Jobs. It does this by allowing you to simulate various types of failures and glitches that can occur in a production environment.
+`ChaoticJob` provides a set of tools to help you test the reliability and resilience of your Active Jobs. It does this by allowing you to simulate various types of failures and glitches that can occur in a production environment, inspired by the principles of [chaos testing](https://principlesofchaos.org) and [deterministic simulation testing](https://blog.resonatehq.io/deterministic-simulation-testing)
 
 ## Installation
 
@@ -59,29 +59,29 @@ end
 
 But, this method does not behave as you would expect. Functionally, it overwrites the `enqueue` method to immediately perform the job, which means that instead of your job being performed in waves, the retry is performed _within_ the execution of the original job. This both confuses the logs and means the behavior in your tests are not representative of the behavior in production.
 
-In order to properly test job retries, you should use the `perform_all` method provided by `ChaoticJob::Helpers`:
+In order to properly test job retries, you should use the `perform_all_jobs` method provided by `ChaoticJob::Helpers`:
 
 ```ruby
 Job.perform_later
-perform_all
+perform_all_jobs
 ```
 
 This helper will perform the job and all of its retries in the proper way, in waves, just like it would in production.
 
-If you need more control over which batches of jobs are performed, you can use the `perform_all_before` and `perform_all_after` methods. These are particularly useful if you need to test the behavior of a job that schedules another job. You can use these methods to perform only the original job and its retries, assert the state of the system, and then perform the scheduled job and its retries.
+If you need more control over which batches of jobs are performed, you can use the `perform_all_jobs_before` and `perform_all_jobs_after` methods. These are particularly useful if you need to test the behavior of a job that schedules another job. You can use these methods to perform only the original job and its retries, assert the state of the system, and then perform the scheduled job and its retries.
 
 ```ruby
 JobThatSchedules.perform_later
-perform_all_before(4.seconds)
+perform_all_jobs_before(4.seconds)
 assert_equal 1, enqueued_jobs.size
 assert_equal 2, performed_jobs.size
 
-perform_all_after(1.day)
+perform_all_jobs_after(1.day)
 assert_equal 0, enqueued_jobs.size
 assert_equal 3, performed_jobs.size
 ```
 
-You can pass either a `Time` object or an `ActiveSupport::Duration` object to these methods. And, to make the code as readable as possible, the `perform_all_before` is also aliased as the `perform_all_within` method. This allows you to write the example above as `perform_all_within(4.seconds)`.
+You can pass either a `Time` object or an `ActiveSupport::Duration` object to these methods. And, to make the code as readable as possible, the `perform_all_jobs_before` is also aliased as the `perform_all_jobs_within` method. This allows you to write the example above as `perform_all_jobs_within(4.seconds)`.
 
 ### Simulating Failures
 

data/lib/chaotic_job/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module ChaoticJob
-  VERSION = "0.1.1"
+  VERSION = "0.2.0"
 end

data/lib/chaotic_job.rb

@@ -40,19 +40,16 @@ module ChaoticJob
   end
 
   module Helpers
-    def perform_all
+    def perform_all_jobs
       Performer.perform_all
     end
 
-    def perform_all_within(time)
-      Performer.perform_all_within(time)
-    end
-
-    def perform_all_before(time)
+    def perform_all_jobs_before(time)
       Performer.perform_all_before(time)
     end
+    alias_method :perform_all_jobs_within, :perform_all_jobs_before
 
-    def perform_all_after(time)
+    def perform_all_jobs_after(time)
       Performer.perform_all_after(time)
     end
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: chaotic_job
 version: !ruby/object:Gem::Version
-  version: 0.1.1
+  version: 0.2.0
 platform: ruby
 authors:
 - Stephen Margheim