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

Fake.DotNet.Testing.Expecto #1871

Merged
merged 6 commits into from
Apr 20, 2018
Merged

Fake.DotNet.Testing.Expecto #1871

merged 6 commits into from
Apr 20, 2018

Conversation

jackfoxy
Copy link
Contributor

Does not support netstandard1.6
netstandard1.6 does not support ProcessStartInfo.EnvironmentVariables, and I don't think the effort at rewrite is justified

@matthid
Copy link
Member

matthid commented Apr 15, 2018

@jackfoxy Not that I'm specifically interested in netstandard1.6. But why don't we use Fake.Core.Process here? This way some other features will be available for this module as well (for example closing timed-out processes at the end of the fake script)

@jackfoxy
Copy link
Contributor Author

jackfoxy commented Apr 15, 2018

@matthid how exactly do you envision that working? run returns ().
Add a timeout TimeSpan to the ExpectoParams?

@jackfoxy
Copy link
Contributor Author

@matthid if you like this https://github.com/jackfoxy/FAKE/blob/8405a1621ec2d9d5521bc31abcb8dc3b4a7fa51a/src/app/Fake.DotNet.Testing.Expecto/Expecto.fs#L96 better, I will merge into the PR.

Add a timeout TimeSpan to the ExpectoParams?

@matthid
Copy link
Member

matthid commented Apr 15, 2018

Yes I think it is better. I don't think we need timeout. I just wanted to say that using the Fake.Core.Process module has some advantages over raw framework APIs.

Btw do we need to redirect output of expecto? I think maybe Process.execSimple is enough here?

@jackfoxy
Copy link
Contributor Author

@matthid PR updated
I'm suffering under the slow intellisense resolution of VS, which makes API discovery clunky. I may have to switch to Ionide, like everyone else.

Copy link
Member

@matthid matthid left a comment

Choose a reason for hiding this comment

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

Looks good thanks! I just broke some of the code with the latest release (sorry). Could you try to get it to green again? (Let me know if you need help)


open Fake.Core
open Fake.Core.Environment
open Fake.Core.StringBuilder
Copy link
Member

Choose a reason for hiding this comment

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

RequireQualifiedAccess was added to StringBuilder in rc005

@@ -0,0 +1,135 @@
/// Contains tasks to run [Expecto](https://github.com/haf/expecto) unit tests.
module Fake.DotNet.Testing.Expecto
Copy link
Member

Choose a reason for hiding this comment

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

I think we should add RequireQualifiedAccess here

module Fake.DotNet.Testing.Expecto

open Fake.Core
open Fake.Core.Environment
Copy link
Member

Choose a reason for hiding this comment

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

RequireQualifiedAccess was added to Environment in rc005

Copy link
Contributor Author

@jackfoxy jackfoxy Apr 15, 2018

Choose a reason for hiding this comment

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

I think more than happened to RequireQualifiedAccess Environment.

I now get this runtime error

Your environment variables look like they are set manually, but you are missing the default variables. Use the `Process.` helpers to change the 'Environment' field to inherit default values! See https://github.com/fsharp/FAKE/issues/1776#issuecomment-365431982

I had to change env variable handling.

Copy link
Member

Choose a reason for hiding this comment

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

This was introduced somewhere in the beta phase. This will prevent incorrect usage of the API. Basically you almost always want to inherit the default environment variables, but you replaced them with your own map -> this error occurs.

UseShellExecute = false
// Pass environment variables to the expecto console process in order to let it detect it's running on TeamCity
// (it checks TEAMCITY_PROJECT_NAME <> null specifically).
Environment = environVars() |> Map } )
Copy link
Member

Choose a reason for hiding this comment

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

Can we just leave it out? I think this is the default.

open System

/// CLI parameters available if you use Tests.runTestsInAssembly defaultConfig argv in your code:
type ExpectoParams =
Copy link
Member

Choose a reason for hiding this comment

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

As it is part of the Expecto-module we could

  • either call it Params (if we want to, users would then use Expecto.Params)
  • move it out of the Expecto module and leave it ExpectoParams

What do you think? We probably even should have some guideline around this and make it more uniform in fake 6

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Shortening to Params.

@jackfoxy
Copy link
Contributor Author

PR updated

WorkingDirectory = workingDir }
// Pass environment variables to the expecto console process in order to let it detect it's running on TeamCity
// (it checks TEAMCITY_PROJECT_NAME <> null specifically).
|> Process.setEnvironmentVariables (Environment.environVars()) )
Copy link
Member

Choose a reason for hiding this comment

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

It should be working by just deleting this like. AFAICS you don't add any special environment variables or remove them, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just copied over this from the legacy code based on the comment. Removed.

@jackfoxy
Copy link
Contributor Author

jackfoxy commented Apr 17, 2018

@matthid perhaps the comment about travis and environment variables is to be taken seriously? Travis build failed.

@jackfoxy
Copy link
Contributor Author

I really could not tell from the raw travis log why it failed.

@jackfoxy
Copy link
Contributor Author

@matthid the best I can determine from the Travis log is it stalled for unknown (to me) reason.

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

The build has been terminated

@matthid matthid changed the base branch from master to rc_6 April 20, 2018 16:51
@matthid
Copy link
Member

matthid commented Apr 20, 2018

I'll try to figure out what's wrong

@matthid matthid merged commit 4f8e42d into fsprojects:rc_6 Apr 20, 2018
@jackfoxy jackfoxy deleted the expecto5 branch April 20, 2018 20:13
@matthid matthid mentioned this pull request Apr 22, 2018
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.

2 participants