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
JUnit tests fail due to missing hello-world.git on GitHub #1275
Comments
Either that, or have test repositories zipped and checked in to the project as a test resource. I would actually see benefit in the latter as it allows for running tests in an environment where you don't have access to GitHub repos, and you also always have a well defined state of the repository used for tests, which also enabled running tests writing to the repository. |
This is similar to #1126 . I recommend creating repositories at runtime. Having a fixed or read-only repositories confines you to having that specific repository in that specific state. Any modifications done to the repository during a test, like deleting a branch, has to be undone for the next test otherwise they will fail. As tests need to expand to cover more areas, it will cause the read-only repository to become huge and bloated as more and more has to be added to it. |
I'm not sure how the leadership hierarchy works for the project, or how decisions are usually made. Which method should I go for? Or do I just choose the one that makes the most sense to me? Personally I think zipping up the data and keeping it in the test sources makes the most sense, but I'd still like to contribute according to your guidelines |
Creating a repo on-the-fly for each test has the benefit that it is more easily adjustable and extendible. It has the drawback that with a lot of tests it can explode into a lot of code for creating repos and an increased runtime for tests. Go with your gut feeling and choose what makes most sense to you. That way you will be most comfortable with implementing it. The task of creating repositories to get tests working alone is a big task, be they dynmically or statically created, so keep the barrier for yourself low. Both way will help immensly and can be used not only for read-only tests but also for read-write tests. I guess that in the future we will end up with a mix of both. But as rnveach has mentioned, having read-only repositories for tests is limiting. There is also merit in read-only, remote repositories, for example for testing the mirror functionality. But the quickest win right now will be in something that makes existing tests work again, and that can help with existing bug reports that require repo interaction to get tested. |
I have recently discovered that repository "https://github.com/git/hello-world.git" referenced in JUnit tests had disappeared from GitHub and does not exist anymore.
For this reason a number of JUnit tests fail.
Could not all repositories used in tests be forked into "gitblit" account on GutHub in order to make them independent?
This is probably a big simile towards James, the author and owner. 😄
The text was updated successfully, but these errors were encountered: