-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Tests For API Asset Store + Refactor For Auto Increment & Form Requests #13964
Tests For API Asset Store + Refactor For Auto Increment & Form Requests #13964
Conversation
PR Summary
|
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.
Ah, we broke some other tests because the Asset's factory doesn't adhere to the rules that were added. I made a comment about how to update the factory for order_number
to get us back to green.
Might be helpful but my process for finding the issues was to drop a dd($asset)
right after Asset::factory()->create()
in a test that was failing, seeing what errors were in the validationErrors
property, then updating the factory, and repeating.
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.
This tests are making me 🥲 😄
Solid work 🎉
$this->assertEquals($userAssigned->id, $asset->assigned_to); | ||
$this->assertTrue($asset->company->is($company)); | ||
// I don't see this on the GUI side either, but it's in the docs so I'm guessing that's a mistake? It wasn't in the controller. | ||
// $this->assertEquals('2023-09-03', $asset->last_audit_date); |
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.
@snipe can verify but yeah I think it can be removed...
$this->assertTrue($apiAsset->adminuser->is($user)); | ||
$this->assertTrue($apiAsset->checkedOutToAsset()); | ||
// I think this makes sense, but open to a sanity check | ||
$this->assertTrue($asset->assignedAssets()->find($response['payload']['id'])->is($apiAsset)); |
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 also think this makes sense... 😅
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 feel like this is a masterclass on how to write PR's. It has everything I like:
- TONS of new tests
- a full explanation of why the choices that were made were made in the PR description
- comments in the tricky bits - e.g. "This looks weird, why are we doing this?"
- additional sprinkles of static typing when it's appropriate
- Lovely cleanups of some verbose code
I'm going to want to take this for a spin, but this looks absolutely exquisite and I can't wait to get it live. Nice work! As soon as I've run through some smoke-testing I'll approve it and try to get it merged.
@@ -131,9 +131,6 @@ public function store(ImageUploadRequest $request) | |||
$asset->order_number = $request->input('order_number'); | |||
$asset->notes = $request->input('notes'); | |||
$asset->user_id = Auth::id(); | |||
$asset->archived = '0'; | |||
$asset->physical = '1'; | |||
$asset->depreciate = '0'; |
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.
It's possible we put these defaults in here so that MySQL doesn't throw up on them if they're null and the db field is not nullable.
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.
archive
anddepreciate
are both defaulted at the db level to what we were setting them to, so we shouldn't notice any difference there.physical
is not defaulted at the db level, but it is nullable, and I couldn't find any evidence of it being used anywhere.
I think we're good and I never got it to error.
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.
We've been bitten by that before though. If you pass it and it's null, without mutators (like we did for qty), it can cause MySQL to crash out.
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.
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.
Tests added.
Just pulled it down, and the first thing I did is run all of the tests - I did see two that didn't pass from our lovely new test suite, so I'm going to see if there's something simple that we can fix there, or if we have something deeper I need to look at. I'll report back. If I get stuck, or it seems too heavy for me to handle, I'll just set the PR to "request changes." |
Ah! Okay, it seems like the test passes in MySQL, but fails in SQLite. While we don't really like supporting alternate databases, we do kinda-sorta try and do it, when we can. (If it fails in SQLite, it might also fail on PostgreSQL, which we do have some users on. So I think if we can fix this to pass there, we should be in good shape. I think it may also be possible that this failure could be related to [SC-24174] - which I may also have some thoughts on. If we can fix this as it is, without fixing [SC-24174], then that would be great! I would rather not conflate the two together :/ |
This pull request has been linked to Shortcut Story #24174: Auto-increment can exceed BIGINT mysql limitations and crash out. |
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.
LOVE the new tests btw! As I mentioned in my comment these all PASS in MySQL - but I get two failures in SQLite. Seems to possibly be related to asset tags? Anyways, more details in the comments.
If we can get this to pass in both database, I'm ready to approve it!
I'll work on that this week at some point. Thanks! |
@@ -20,7 +20,20 @@ public function authorize(): bool | |||
|
|||
public function prepareForValidation(): void | |||
{ | |||
// | |||
// this needed to be added in because the observer fails if `assigned_to` is null :shrug: |
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.
Why tho?
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.
Can't remember, and that's a dumb comment on my part, I'll look back into it this week and try to remember exactly what the deal was.
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.
@snipe i removed that bit and everything seems to be working fine and checkout tests are still passing. not totally sure what it was about, it may have been failing before i finished getting the rules array set up and i put it in as a stop gap.
@uberbrady tests fixed for SQLite (problem was 'next_auto_tag_base' in settings for |
Description
This is fairly large but I think will end up being a good simplification of some things.
I've refactored the
store()
method in the controller to just->fill($request->validated())
with the already validated attributes from the form request, just makes things a little more concise and reduce some duplication (will be really nice when this gets applied to the GUI controller as well - hopefully next week 🤞).The only real effect this has is now basically everything needs to be included on the rules array in the model. I didn't change to using
Asset::create()
so we still have access to everything we're used to, and I even left a couple of things in the model that make more sense there - like$asset->user_id = Auth::id();
The way I think about it, anything a user is setting should be included in the validation rules, and anything we're setting explicitly should be set in the controller still.
I also got rid of setting
archived
,depreciate
, andphysical
in the controller.archive
anddepreciate
are both defaulted at the db level to what we were setting them to, so we shouldn't notice any difference there.physical
is not defaulted at the db level, but it is nullable, and I couldn't find any evidence of it being used anywhere. In fact, I could only findarchived
being used in a single scope, but decided to leave it be for now as it should continue to work the same.last_audit_date
was included in the documentation, but wasn't in the controller, since that's not in the validation rules right now it will continue to not be set if included in the request.A good amount of tests have been added, and I'm happy to go add any more that we feel we're missing now that I've got a handle on how to do that.
The AutoIncrement function seems to work just fine at the
prepareForValidation()
method (and there's a test written for this as well).Thanks to @marcusmoore for help with tests (and for having already written a couple 🙂)
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Tested manually and also wrote some tests.
Test Configuration: