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

Move coreapi tests to the interface #5865

Merged
merged 6 commits into from
Jan 4, 2019
Merged

Move coreapi tests to the interface #5865

merged 6 commits into from
Jan 4, 2019

Conversation

magik6k
Copy link
Member

@magik6k magik6k commented Dec 20, 2018

Needs to be done before interface extraction

@magik6k magik6k added kind/test Testing work topic/core-api Topic core-api labels Dec 20, 2018
@magik6k magik6k requested a review from Kubuxu as a code owner December 20, 2018 20:06
@ghost ghost assigned magik6k Dec 20, 2018
@ghost ghost added the status/in-progress In progress label Dec 20, 2018
@magik6k magik6k added need/review Needs a review and removed status/in-progress In progress labels Dec 20, 2018
@magik6k magik6k changed the title Move coreapi tests ont the interface Move coreapi tests to the interface Dec 20, 2018
@magik6k magik6k mentioned this pull request Dec 20, 2018
51 tasks
@ghost ghost added the status/in-progress In progress label Dec 20, 2018
@eingenito
Copy link
Contributor

Hey @magik6k, I'm taking a look at this and I can follow what you did mechanically, but I don't understand why you did it? I have some questions; I apologize if they don't make sense.

  • What's the extraction you're referring to in the initial comment?
  • What's the motivation for tracking contexts as you do here? Has this been an issue in CI or something?
  • I think this will prevent us from running any of these tests individually? Is that a big deal?

Any other context you could provide quickly would be great. I get that I might just be the wrong reviewer but you mentioned this PR about two weeks ago and I wanted to get you some feedback. Thanks.

select {
case <-zeroRunning:
case <-time.After(time.Second):
t.Errorf("%d node(s) not closed", running)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: we're not really tracking nodes here right? More like constructed swarms.

@magik6k
Copy link
Member Author

magik6k commented Jan 3, 2019

What's the extraction you're referring to in the initial comment?

ipfs-inactive/interface-js-ipfs-core#66, basically we don't want external implementations of coreapi to depend on go-ipfs repo

What's the motivation for tracking contexts as you do here? Has this been an issue in CI or something?

go-ipfs-http-api uses IPTB to spawn nodes and relies on contexts to kill those nodes.

I think this will prevent us from running any of these tests individually? Is that a big deal?

Running all coreapi tests takes about 3-4s for the core/coreapi implementation on my PC. It will probably be much slower with http-api+IPTB, but filtering with -run still works just fine (e.g. go test github.com/ipfs/go-ipfs/core/coreapi/test -run='TestIface/Object/TestObjectPut' -v)

License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
License: MIT
Signed-off-by: Łukasz Magiera <magik6k@gmail.com>
Copy link
Contributor

@eingenito eingenito left a comment

Choose a reason for hiding this comment

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

I don't fully understand the refactor going on, but I trust you do. I had no important comments, only one tiny thing.

if err != nil {
t.Error(err)
}

res, err := api.Block().Put(ctx, strings.NewReader(`Hello`))
if err != nil {
t.Error(err)
t.Fatal(err)
Copy link
Contributor

Choose a reason for hiding this comment

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

What's the pattern for the replacement of Error with Fatal? Are we testing the first use of the CoreAPI generally?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think I understand - it's an existing inconsistency and you didn't want to change them wholesale.

Copy link
Member Author

Choose a reason for hiding this comment

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

TBH I just started changing them here as I was working on running tests in go-ipfs-http-api and this got committed. I'll commit more of those fixes in another PR.

func TestGenerateType(t *testing.T) {
ctx := context.Background()
func (tp *provider) TestGenerateType(t *testing.T) {
ctx, cancel := context.WithCancel(context.Background())
Copy link
Contributor

Choose a reason for hiding this comment

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

These could go below skip?

Copy link
Member

Choose a reason for hiding this comment

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

(yes but I didn't see that comment before I merged... oh well, it doesn't really matter much).

@Stebalien Stebalien merged commit 821c36c into master Jan 4, 2019
@ghost ghost removed the status/in-progress In progress label Jan 4, 2019
@hacdias hacdias deleted the feat/coreapi-tests branch May 9, 2023 10:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/test Testing work need/review Needs a review topic/core-api Topic core-api
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants