Skip to content
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

Fix testCaseTask to accept a task, not an Async #484

Merged
merged 3 commits into from
Nov 24, 2023
Merged

Conversation

farlee2121
Copy link
Collaborator

Fix testCaseTask to accept a task, not an Async. Also fix test name conflicts.

I noticed this was causing build troubles when I went back to the interactive PR, so I fixed it.

@@ -1396,57 +1396,61 @@ let taskTests =
fun ms -> task { return ms.CanWrite ==? true }
]

testCaseTask "simple" <| task {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't change any of the tests, just grouped them with testList to fix the name conflict

@@ -88,23 +88,23 @@ module Tests =
/// Builds an async test case
let inline testCaseAsync name test = TestLabel(name, TestCase (Async test,Normal), Normal)
/// Builds an async test case from a task
let inline testCaseTask name test = TestLabel(name, TestCase (Async test,Normal), Normal)
let inline testCaseTask name test = TestLabel(name, TestCase (Async (Async.AwaitTask test),Normal), Normal)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was the main fix. testCaseTask and it's variants were expecting an Async instead of a Task

// ==> "All"
// ==> "Push"
// ==> "Release"
"CheckEnv"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is why the build didn't fail it before

@farlee2121
Copy link
Collaborator Author

For some reason these two tests fail on the build server

  • performance cryptography tests.md5 versus sha256
  • performance cryptography tests.sha256 versus md5

Perhaps some cross-platform nonsense going on here

@farlee2121
Copy link
Collaborator Author

Not really sure why those cryptography tests exist, there are other tests that verify Expect.isFasterThan.

It doesn't seem like it should be, but the tests failing does seem to be a platform issue. I booted up a codespace and got the same result as the build server...

@ratsclub
Copy link
Collaborator

Other than the small comment I made, this seems nice!

@farlee2121
Copy link
Collaborator Author

Hmm. I'm not seeing the comment.

Comment on lines 38 to 39
if RuntimeInformation.IsOSPlatform(OSPlatform.Linux) then
skiptest "Doesn't hold true on this platform for unclear reasons"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's appropriate to remove them or write some other test to replace it!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hesitant to remove them, since I don't quite understand the purpose of the tests.
But it also seems like the same functionality is already covered by these tests.

I think I'll just go ahead and remove them

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@farlee2121 farlee2121 merged commit a36ff46 into main Nov 24, 2023
3 checks passed
@TheAngryByrd
Copy link
Contributor

👋 I know this review is a little late but these should really take a unit -> Task or unit -> Task<unit>. Problem with just using task, is they are hot meaning it will run immediately. This will be a problem when using p on testLists and such.

@farlee2121
Copy link
Collaborator Author

That's a very good point. Hmm. I'm not sure how we handle that since it's already out there.
It just went out hours ago though, so no one should have ingrained it into their code yet.

@farlee2121
Copy link
Collaborator Author

farlee2121 commented Mar 15, 2024

Looking a bit closer, this actually represents a breaking change to testTask. It previously was properly wrapping the task in an async that would defer execution.

let a = async {
        do! task.Run f |> Async.AwaitTask
    }

In that light, I think the lesser evil here is to quickly release a patch update. It breaks the new endpoints we just introduced, but fixes the defect in testTask and aligns testCaseTask with the previous expected behavior

@farlee2121
Copy link
Collaborator Author

@TheAngryByrd @ratsclub I whipped up a PR with a potential resolution, #492, if you'd be so kind as to provide thoughts

@farlee2121 farlee2121 deleted the testCaseTask-typing branch April 12, 2024 19:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants