Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

capture range variable for parallel testing #2346

Merged

Conversation

kwk
Copy link
Collaborator

@kwk kwk commented Nov 9, 2018

Before only the last range variable was being used and some tests just passed when the shouldn't have.

See also https://gist.github.com/posener/92a55c4cd441fc5e5e85f27bca008721.

And https://golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks for capturing range variables.

Thanks to @michaelkleinhenz for finding this and @jarifibrahim for finding the solution which is well known but in this case it is just too easy to miss.

@kwk kwk self-assigned this Nov 9, 2018
@alien-ike alien-ike changed the title WIP: capture range variable for parallel testing capture range variable for parallel testing Nov 9, 2018
@alien-ike alien-ike changed the title WIP: capture range variable for parallel testing capture range variable for parallel testing Nov 9, 2018
@kwk kwk changed the title capture range variable for parallel testing WIP: capture range variable for parallel testing Nov 12, 2018
@codecov
Copy link

codecov bot commented Nov 12, 2018

Codecov Report

Merging #2346 into master will increase coverage by 0.07%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2346      +/-   ##
==========================================
+ Coverage   70.17%   70.24%   +0.07%     
==========================================
  Files         171      171              
  Lines       16625    16625              
==========================================
+ Hits        11666    11678      +12     
+ Misses       3829     3821       -8     
+ Partials     1130     1126       -4
Impacted Files Coverage Δ
workitem/simple_type.go 84.21% <0%> (+1.31%) ⬆️
workitem/enum_type.go 93.75% <0%> (+7.5%) ⬆️
workitem/link/topology.go 100% <0%> (+21.05%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 829eb51...ad8cd52. Read the comment docs.

@kwk kwk changed the title WIP: capture range variable for parallel testing capture range variable for parallel testing Nov 12, 2018
@kwk kwk merged commit 5205666 into fabric8-services:master Nov 13, 2018
@kwk kwk deleted the capture-range-variables-in-parallel-tests branch November 13, 2018 09:16
kwk pushed a commit to openshiftio/saas-openshiftio that referenced this pull request Nov 22, 2018
**Commit:** fabric8-services/fabric8-wit@bbd8f88
**Author:** Konrad Kleine (193408+kwk@users.noreply.github.com)
**Date:** 2018-10-29T12:14:17+01:00

Add 'None' as default resolution for defect (fabric8-services/fabric8-wit#2334)

Add `None` to a Defect's resolution in the Agile space template and make it the default resolution by putting it in first place.

See openshiftio/openshift.io#3832

----

**Commit:** fabric8-services/fabric8-wit@d070588
**Author:** Konrad Kleine (193408+kwk@users.noreply.github.com)
**Date:** 2018-10-30T12:59:57+01:00

Fixup for bbd8f88c789943293680644ae8a49b5342a55575 fabric8-services/fabric8-wit#2334 (fabric8-services/fabric8-wit#2336)

Previously the [deployment failed](fabric8-services/fabric8-wit#2334 (comment)):

```
failed to overwrite default of old field type with None (string):
failed to set default value of enum type to None (string):
value: None (string) is not part of allowed enum values:
[Done Duplicate Incomplete Description Can not Reproduce Deferred Won't Fix Out of Date Verified]
file: spacetemplate/importer/repository.go
line: 91
```

We've updated the resolution enum to
have a new value and that is also the new default. That new value didn't
exist in the old enum type but we tried to make it the new default for
the old type anyways. That didn't work because the `FieldType.SetDefault()`
implementation for enums checks if the given value is part of the
allowed enum values.

The overall intention is to check if too enums are the same but ignore
the default value. That is why we temporarily make both defaults the
same before we call `FieldType.Equal()`.

With this change we simply reverse the assignment of the new default to
the old type. Instead we temporarily assign the old default to the new
type. The result is that a call to `FieldType.Equal()` will return true.

----

**Commit:** fabric8-services/fabric8-wit@9dc1c08
**Author:** Konrad Kleine (193408+kwk@users.noreply.github.com)
**Date:** 2018-10-30T15:53:19+01:00

Added .github/CODEOWNERS file (fabric8-services/fabric8-wit#2339)

We want to use this file in Github to automatically assign reviewers to PRs if they are declared as "owners".

Read more about this file here:

* https://blog.github.com/2017-07-06-introducing-code-owners/
* https://help.github.com/articles/about-codeowners/

So far I've added only "my" parts and the ones I feel deeply responsible for.

We can add more code owners later.

----

**Commit:** fabric8-services/fabric8-wit@829eb51
**Author:** Ibrahim Jarif (jarifibrahim@gmail.com)
**Date:** 2018-11-12T19:22:40+05:30

Rename SystemBoardColumns to BoardColumns in workitem relationships (fabric8-services/fabric8-wit#2345)

----

**Commit:** fabric8-services/fabric8-wit@5205666
**Author:** Konrad Kleine (193408+kwk@users.noreply.github.com)
**Date:** 2018-11-13T10:16:37+01:00

capture range variable for parallel testing (fabric8-services/fabric8-wit#2346)

Before only the last range variable was being used and some tests just passed when the shouldn't have.

See also https://gist.github.com/posener/92a55c4cd441fc5e5e85f27bca008721.

And https://golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks for capturing range variables.

Thanks to @michaelkleinhenz for finding this and @jarifibrahim for finding the solution which is well known but in this case it is just too easy to miss.

----

**Commit:** fabric8-services/fabric8-wit@c81a4d2
**Author:** Preeti Chandrashekar (preetipagad@gmail.com)
**Date:** 2018-11-17T16:34:10+05:30

Adds infotips for Work Items WIG (fabric8-services/fabric8-wit#2266)

----
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants