Out of curiosity, is there a reason why dlg.show() is used instead of dlg.render() and then dlg.show()?
Some things you can try,

- playing around between spyOn(view, '_someFunc').and.callThrough(); and spyOn(RB.SomeView.prototype, '_someFunc').and.callThrough();. I found that the former is good for testing elements that are child elements of the parent view that is rendered. The latter is good for testing a function that is within the same parent view you're testing.

- using view.delegateEvents(); if there's child element functions to test. It looks like you're testing with an input (child) within the parent(uploadAttachmentView), this looks like a good case to use it. You would call delegateEvents after initializing the spy.
Example,
     // render the parent view

     // _onSelectDiffFileKeyDown is triggered by a specific button(child). $path would be the child in this scenario
     spyOn(parentview, '_onSelectDiffFileKeyDown').and.callThrough();

     // make sure child functions will be called
     parentview.delegateEvents();

     const selectDiffFileButton = parentview.$el.find('#select-diff-file');
     keyEvent.which = $.ui.keyCode.ENTER;
     selectDiffFileButton.trigger(keyEvent);
     expect(parentview._onSelectDiffFileKeyDown).toHaveBeenCalled();



I know Christian said order doesn't matter when setting up the spies (but it did for me :P ). If you're using spyOn(view, '_someFunc').and.callThrough();, a view should be rendered afterwards. For spyOn(RB.SomeView.prototype, '_someFunc').and.callThrough(); the view should be rendered before the spy is created. 
Using $testsScratch to make sure the dialog is actually being attached to the DOM. 
Maybe instead of directly using $path.trigger('change'), declare a event = $.Event('change'); and pass that in to trigger or triggerHandler instead? Not sure if that'll work

I know its not a finished review request yet but also changing dlg to dialog will help out too as I didn't get that abbreviation right away.

Just some minor things to address but otherwise the test contents itself are solid :)

If this function is empty, could we remove it?

Change this to UploadAttachmentView instances

Remove the blank line

Turn to Cancel Button instead.
Both David and Christian stress that test descriptions should be as clear as possible so it's easier to traverse through errors when the entire suite runs.

Turn this to Upload Button

Minor code styling issue to fix, just need to line up the line like this below

spyOn(dialog, 'updateUploadButtonEnabledState')
     .and.callThrough();

Maybe change this to Disabled by default until a file is uploaded to make it clear it is disabled by default

Since expect(dialog.updateUploadButtonEnabledState).toHaveBeenCalled(); is being called more than once in this test function, maybe be more specific with how many times this is being called.
expect(dialog.updateUploadButtonEnabledState).toHaveBeenCalledTimes(1);
or instead at the very end of the function,
expect(dialog.updateUploadButtonEnabledState).toHaveBeenCalledTimes(2);

I'm kind of unclear on what this test is supposed to do. Correct me with I'm wrong.

Show a dialog with preloaded information
Check if caption and history has been updated based on this preloaded information?

Initially at first I thought this test would check if the caption got updated to a new value different from the preloaded one or the content of the dialog changes and we check if the history got incremented by one.

This should be rb/views/UploadAttachmentView (class capitalization).

For ES6 JavaScript, the last item in a list or object should have a trailing comma.

When using let or const, we should list one variable per statement. So:

let dialog;
let $caption;
let $attachmentHistory;


Alphabetical order is always appreciated.

Blank line between these.
Though, it'd probably make more sense to move dialog = null into the conditional.

Only one test needs this, so it should move into that test.

Since this is a precondition sanity-check for test setup, it should move into beforeEach()

One per statement.

Multi-line comments should be in the form of:

/*
 * ...
 * ...
 */


Each comment should also have proper sentence capitalization and punctuation.

Single quotes are preferable so long as content doesn't need to use a single quote.

Similarly, this should move into beforeEach().

This is going to result in something like Blah blah blah                           blah
This really sounds more like two tests. I'd have one that tests just setting the file and asserts around that, and a second that sets things up by setting the file and then tests the removal case.

This should use single quotes.

I'd suggest chaining the statements:

$path
    .val('')
    .trigger('change');


Same with similar code paths below.

This statement exceeds the max line length limit. You should wrap at .toHave.....

This should use single quotes.

This statement exceeds the max line length limit.

This statement exceeds the max line length limit.
Also, the context for this test is "Buttons -> Upload", so we can get rid of the "Clicking upload ...". Maybe just make this "Uploads the file attachment".

Can you inverse the types of quotes: '[name="caption"] is more consistent with our standards.

Making some tiny tweaks and landing. Thanks!