ktrysmt/go-bitbucket

Error when running tests

ebh opened this issue · 8 comments

ebh commented

Steps to reproduce

  1. Cloned repo to my local machine
  2. Set the values for and run:
export BITBUCKET_TEST_USERNAME=<your_username>
export BITBUCKET_TEST_PASSWORD=<your_password>
export BITBUCKET_TEST_OWNER=<your_repo_owner>
export BITBUCKET_TEST_REPOSLUG=<your_repo_name>
  1. Run make test

Expected outcome

  • All tests passed

Actual outcome

go test -v ./tests
=== RUN   TestCreateBranchRestrictionsKindPush
--- FAIL: TestCreateBranchRestrictionsKindPush (1.19s)
panic: interface conversion: interface {} is nil, not map[string]interface {} [recovered]
        panic: interface conversion: interface {} is nil, not map[string]interface {}

goroutine 19 [running]:
testing.tRunner.func1.1(0x1311e40, 0xc00009dad0)
        /usr/local/Cellar/go/1.15.5/libexec/src/testing/testing.go:1072 +0x30d
testing.tRunner.func1(0xc000082900)
        /usr/local/Cellar/go/1.15.5/libexec/src/testing/testing.go:1075 +0x41a
panic(0x1311e40, 0xc00009dad0)
        /usr/local/Cellar/go/1.15.5/libexec/src/runtime/panic.go:969 +0x1b9
github.com/ktrysmt/go-bitbucket/tests.TestCreateBranchRestrictionsKindPush(0xc000082900)
        /Users/alexdess/ebh-services/go-bitbucket/tests/branchrestrictions_test.go:48 +0x325
testing.tRunner(0xc000082900, 0x137e428)
        /usr/local/Cellar/go/1.15.5/libexec/src/testing/testing.go:1123 +0xef
created by testing.(*T).Run
        /usr/local/Cellar/go/1.15.5/libexec/src/testing/testing.go:1168 +0x2b3
FAIL    github.com/ktrysmt/go-bitbucket/tests   1.517s
FAIL
make: *** [test] Error 1

Further investigation

I run the tests individually:

  • go test -v ./tests/branchrestrictions_test.go - FAIL
  • go test -v ./tests/client_test.go - PASS
  • go test -v ./tests/diff_test.go - FAIL
  • go test -v ./tests/list_test.go - PASS
  • go test -v ./tests/repository_test.go - PASS
  • go test -v ./tests/user_test.go - FAIL
  • go test -v ./tests/workspace_test.go - FAIL

Suggested Improvement

Use Github Actions to run tests automatically

Thank you for your report. I am going to do it.

ebh commented

I actually had a bit of a go at adding Github Actions, see #112.

FWIW I ran into the same issue locally. It's not obvious from the error, unfortunately, but the root cause is that BitBucket's API returns an error result when you try to create a branch restriction that already exists. In other words, that test is not idempotent and cannot be run successfully more than once in it's current state.

I believe there are several separate but related issues that we should address here:

  1. Improve that test so it can be run repeatedly (e.g. delete the newly created branch restriction at the end of the test [see: https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/branch-restrictions/%7Bid%7D] or create a brand new branch each time [see: https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/refs/branches#post], etc.)
  2. Improve the error handling in BranchRestrictions.Create() to better handle the results from BitBucket's v2.0 API when attempting to create a duplicate branch restriction
  3. More generally, and much longer-term, we should investigate ways of testing that don't require actually hitting BitBucket's API endpoints (e.g. MounteBank or some other service virtualization tool)

I see. Some test cases are not repeatable. As I mentioned here, making unit tests and making mock is a heavy task for us. But the test of repeatability may be very important at the current stage of the product. Because, at first, this had started a hobby-ish product, but today it is fortunately growing up by many contributors and it seems be used a couple or some developers.

Although a just idea, I was trying to use swagger refactoring this product there. Then I had thought to utilize that as client API. But at the moment, I would get used the swagger to a mock server for repeatable testing.

ebh commented

making unit tests and making mock is a heavy task for us

I would like to repeat my offer to do a lot of the grunt work. I have the time this month but will not have as much time come February. The only thing blocking me from getting started is you mentioned you wanted to think about the strategy first.

As I said here, It seems full-scratching api mocks is heavy to maintain for us, I think. But of course, quality control is important.

By the way, I want to try to suggest to use swagger.yaml for launching a mock server to do integration test locally.

e.g. via #96 (comment)

# launch an api-mock server
docker run --rm -it -p 4010:4010 stoplight/prism:3 mock -h 0.0.0.0 https://bitbucket.org/api/swagger.json

# run integrational test
go test -v ./...

If you do not feel so good about that, I would like to take a look some mock|unit tests you write. How do you think about it? @ebh

ebh commented

I've never used Prism before but based on a 5-second read of their website it looks pretty cool :)

Let me have a play and see if I can write one test and get that running as part of CI using Github Actions. If I'm successful I'll raise a PR for you to review. If I'm not successful I'll come back to you for help :)

Note: Might be a couple of days until I get back to you :)

That sounds like a good. Also It will be helpful for me as well. @ebh