✨ Tobias: Issuing a Payout
#11
Labels
Comments
16 tasks
zspencer
added a commit
to zinc-collective/convene
that referenced
this issue
Jan 23, 2024
- zinc-collective#11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](zinc-collective#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](zinc-collective#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
This was referenced Jan 27, 2024
zspencer
added a commit
that referenced
this issue
Jan 29, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Jan 29, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
This was referenced Jan 29, 2024
zspencer
added a commit
that referenced
this issue
Jan 30, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Feb 12, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Feb 12, 2024
zspencer
added a commit
that referenced
this issue
Feb 27, 2024
zspencer
added a commit
that referenced
this issue
Mar 25, 2024
- #11 I'm starting out by coding by wishful thinking, putting together the pieces of the pie that I can eat bite by bite. In this test, I'm using imagining there will be a Model called `Tobias::Payout`, which will be our computational entrance point into the [Issuing a Payout](#11) feature. I considered starting with a system test, which would have gone through the User Interface and tied together a bunch of different concepts; but I figured I would start with a `model` spec; so that I can stay focused on drawing the computer-facing side of the feature out before worrying too much about the human-facing bits; which I always find require a lot more thought for me. That said, a system test will be useful here at some point. The computational bits, on the other hand, feel pretty accesible. We want to create Payments for every Beneficiary of the appropriate amount, and store records of these Payments so we know who is supposed to get paid what. Here's a line-by-line play-by-play of this change: I'm using the `spec` folder to store executable examples of a feature. Because `Issuing Payout` is a feature for the [`TOBIAS` project](#1), I am storing it under `spec/tobias`. My choice of what to call the file (`payout_spec.rb` indicates that this spec will be for the `Payout` model. The `require "rails_helper"` line tells our testing framework to load all the code necessary to run a spec. The `describe Tobias::Payout do` line groups the examples nested within it as relating to the `Payout` model. The `describe "#issue"` line tells me that the `Payout` model will have a method named `issue`, and also creates a group of examples that describe how the `Payout#issue` method works. The `it "issues a Payment..." do` line describes one of the examples we we plan to use to confirm that the `Payout#issue` method works the way we hope it will. The test itself lives on the lines between `it "issues a Payment..." do` and the `end` that is aligned with the `it` The `payout = create(:tobias_payout, payout_amount_cents: 150_00) line says "create a database record of a `Tobias::Payout, and populate it's `payout_amount_cents` field with $150.00, and store a reference to it in the `payout` variable. The `beneficiaries = create_list(10, :tobias_beneficiary, trust: payout.trust)` line says create 10 `Tobias::Beneficiary` records in the database, and make sure their `trust` field is pointed at the same `Tobias::Trust` that our `payout` is pointing to. Store references to those in the `beneficiaries variable.` The `payout.issue` line executes the `Payout#issue` method that we are describing. The `beneficiaries.each do |beneficiary|` goes over every one of the newly created `Tobias::Beneficiary` records stored in the `beneficiaries` variable, expose each one as a variable named `beneficiary`, and execute the code between it and the next `end`. The `expect(beneficiaries.payments).to exist(amount_cents)` tells our example to let us know if there are no `Tobias::Payment` records in the database for one of the `beneficiaries`.
zspencer
added a commit
that referenced
this issue
Mar 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a 💰
Trust#4 has reached a position where it can issue a 💸Payout#8 to every qualifying 💪🏽🧑🏽🔧Benificiary#5, we facilitate calculation, record keeping, and distribution of each 💵Payment#16.For a 💰👩🏽💼
Treasurer#9 to issue a 💸Payout#8 from the 💰Trust#4 to a 💪🏽🧑🏽🔧Benificiary#5, we need a human / computer interface to process a 💸Payout#8.Issuing a Payout is a multi-step process:
Treasurer#9 chooses theTrustthey would like to issue aPayoutfor.Treasurer#9 enters thePayout#amountfor thatTrustTreasurer#9 reviews thePayout, confirming the beneficiaries and amounts are appropriate.Treasurer#9 issues thePayout, instructing theTrust's financial institution to make the transactionsThe text was updated successfully, but these errors were encountered: