-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Execute trades job issue 145 #174
base: main
Are you sure you want to change the base?
Conversation
test/jobs/stock_purchase_job_test.rb
Outdated
|
||
execute_calls = [] | ||
|
||
PurchaseStock.define_singleton_method(:execute) do |order| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wasn't sure how to properly mock things out in minitest, this was what seemed to work?
Did not work do not do this 😅
9273f4d
to
86d3c12
Compare
def withdrawal_amount | ||
-order.purchase_cost | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this a lot. This helps so much with keeping the rest of the code easy to read
end | ||
|
||
test "calculates purchase cost" do | ||
stock = Stock.create(ticker: "EVG", price: 10.00) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can use the fixture stock like you are in the previous test instead of creating a new one.
As context, we want to spare round-trip calls to the database in the test suite whenever we can. One of the toughest parts of Rails app maintenance is cutting down on all the database accesses that creep into the test suite and slow it down over time. Rails itself doesn't help you much in managing this problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to use fixture. Got it, I usually use FactoryBot for these types of tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like FactoryBot. We may eventually want it on this project. I like the idea of using the fixtures for now until we have a compelling reason to switch
assert_equal portfolio_stock, order.portfolio_stock | ||
end | ||
|
||
test "it updates the order status to completed" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have time this weekend to test any failure states?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a failure state at the bottom, required mocha
gem for stubbing (seemed like a popular way in minitest? I tend to use rspec)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if there's a way we can do this without the stub you've written. I don't want to hold up the good work in this PR, though. If you're up for taking a go at rewriting it, I'm happy to pair with you to go over my concerns. If you're not up for that, then I think we should merge this PR in and we can discuss putting follow-up work in a separate issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't have availability for a bit so feel free to do what seems best. The mocking + failure test are contained in the last commit so you could remove that before merging if you don't want mocha added
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been noodling on this. For the kind of fail cases we want to test, are you talking about something like "what if there is not enough money in the account" or something like that @h-m-m ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! I think that's the main situation.
We will run into a problem at some point where the pending orders plus the new order could add up to more than what's in the account. Should that also go in this PR, or should we break that out into a follow-up PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad you asked this because it made me realize some of this logic should maybe live in a more traditional controller request. Can't we process the transactions themselves based on the price the user sees when they make the request. I would think the only part we need to put in a chron job is updating the price of the stock, either at the beginning or end of the trade day. I'm thinking the purchases themselves should just use that number so the user can see a more immediate error message if they don't have enough in their account. Am I making sense? Is there another reason to put the transactions themselves in a job?
- After this job runs we will want to enqueue the `StockPricesUpdateJob`, not sure about that implementation yet
- Multiple portfolio_stocks can exist for a portfolio with different purchase prices
86d3c12
to
b73b345
Compare
- Use mocha for stubbing
Issue #145
portfolio_transaction
andportfolio_stock
for an audit trailTodo:
Enqueue the
StockPricesUpdateJob
once theStockPurchaseJob
is completed