question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Go Test failed sometimes

See original GitHub issue

/kind bug

What steps did you take and what happened: [A clear and concise description of what the bug is.]

One of github action for Go Test failed sometimes, but it succeed when retest.

I’ve check for some cases:

All case failed for either one of these:

    trial_controller_test.go:261: 
        Timed out after 40.000s.
        Expected
            <bool>: false
        to be true
FAIL
    experiment_controller_test.go:350: 
        Timed out after 40.000s.
        Expected
            <bool>: false
        to be true

What did you expect to happen:

If these issue occured just from the network issue, what about increasing the timeout ? Does it make sense ? WYDT ?

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Environment:

  • Kubeflow version (kfctl version):
  • Minikube version (minikube version):
  • Kubernetes version: (use kubectl version):
  • OS (e.g. from /etc/os-release):

Issue Analytics

  • State:open
  • Created 2 years ago
  • Comments:16 (13 by maintainers)

github_iconTop GitHub Comments

2reactions
johnugeorgecommented, Jun 14, 2022

We need to inspect if we have a better solution with gingko v2

1reaction
anencore94commented, Sep 9, 2021

We should have various function names for each test Experiment. For example, TestReconcileJobFailed(t *testing.T), TestReconcileJobAvailableMetrics(t *testing.T), TestReconcileJobUnavailableMetrics(t *testing.T).

Yes, your suggestion is right. But the reaseon why I intended “we couldn’t call the test function as ReconcileTest anymore?” was that I felt handling those 3 cases at once make sense.

However, splitting those 3 would ok.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Testing in Go: Failing Tests - Ilija Eftimov ‍
Golang's testing package promotes two types of failures. The first failure type immediately stops the tests from running. And the second failure ...
Read more >
`go test` prints FAIL with no obvious indication of which test ...
In this case it seems like that last test started, but somehow failed with no output (we would expect to get a ---...
Read more >
Testing Error Cases and Failing Early | Go Tests #2 - YouTube
What is failing early and why should you care? Sometimes it doesn't make sense to continue running a test if one of the...
Read more >
Go Unit Testing | How Compass Does Unit Testing in Golang
The function calls methods of type T to indicate a failure — ex. t.Error() or t.Fail(). The code snippet below shows a function...
Read more >
Reproducing a Flaky Test in Go - InfluxData
It depends on the particular failure mode; some tests may be flaky when there is too much contention, and others may be flaky...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found