Hot answers tagged

76

One of my co-workers maintains that integration tests are all kinds of bad and wrong - everything must be unit-tested, That's a little like saying that antibiotics are bad - everything should be cured with vitamins. Unit tests can't catch everything - they only test how a component works in a controlled environment. Integration tests verify that ...


73

Your coworker is right that everything that can be unit-tested should be unit-tested, and you're right that unit tests will take you only so far and no further, particularly when writing simple wrappers around complex external services. A common way of thinking about testing is as a testing pyramid. It's a concept frequently connected with Agile, and many ...


72

As you mentioned in your question, people fork repositories when they want to make a change the code, because you don't have write access to the original repository (unless you've been added as a collaborator by the owner of the repository). In the forked repository they have write access and can push changes. They may even contribute back to the original ...


41

In our line of work we tend to look for technical reasons, but in my opinion the primary reason isn't technical. If you look at GitHub Help or other GitHub tutorials, forking a repo is one of the major steps for how you "do" GitHub. When people are learning and evaluating GitHub, just about every tutorial out there is going to tell them to fork a repo as ...


33

Yes. You never know when more people might be brought on to the project. Also, repos allow you to rollback when you accidentally add something that doesn't work. You could use git for version control on your own machine without the need for a centralized repo. However, as long as you're using git, you might as well set up a repo on on GitHub. It only ...


25

Git tends to experience performance problems when used with large repositories. To quote Linus: And git obviously doesn't have that kind of model at all. Git fundamnetally never really looks at less than the whole repo. Even if you limit things a bit (ie check out just a portion, or have the history go back just a bit), git ends up still ...


23

You assume the fix does not introduce any new issues and fixes the old ones complete. But lots of fixes are worth a review on their own - and that is probably much easier when the incremental changes can be reviewed separately.


22

Returning IQueryable will definitely afford more flexibility to the consumers of the repository. It puts the responsibility of narrowing results off to the client, which naturally can both be a benefit and a crutch. On the good side, you won't need to be creating tons of repository methods (at least on this layer) — GetAllActiveItems, ...


20

You should put the unit tests in the same repository because otherwise someone has to answer to the question "Where are the tests?" every time the project is handed over from one person to another. References to other repositories tend to get invalid over time when repositories are relocated and people change from one version control system to another. Just ...


20

One possible reason: they have running code that depends on those projects and their build process involves pulling the dependencies from github. Having the fork protects them against breaking changes. For projects that don't tag versions, this is the easiest way to achieve that.


19

The entire point of Github is "social coding". Personally, I fork repositories when: I want to make a change. I think the project is interesting and may want to use it in the future, but have no easier way of saving it for later on the device I'm currently using. I want to use some or all of the code in that repository as a starting point for my own ...


18

Actually, there is little reason NOT to use a code repository. Just the fact that I can easily roll back to any prior version has covered my rear end so many times when I accidentally introduced regression bugs - despite my automated tests. If you need a recommendation - try Mercurial. It's really simple, yet very powerful. I would avoid Git because of its ...


17

SVN works on both case sensitive and case insensitive filesystems, so it must assume the most compatible option, which is case sensitivity.


16

They want [something that can] show their changes across all projects instead of trying to remember what project they made a change [to]. Sourcetree (a free-as-in-beer GUI Git frontend) allows you to register multiple repositories, organise them into logical groups, and then view status across all of them at once: I am not affiliated with them in any ...


15

There doesn't seem to be an argument in favor of the big repo in this thread, so here's one: The advantage of a big repo with all your code in it, is that you have a reliable source of truth. All the state in your overarching project is represented in that repo's history. You don't have to worry about questions like "What version of libA do I need to build ...


13

Unless there exists a specific reason for you to think that each one of them deserves an invidual repo (Will they grow a lot? Probably not!) it seems more reasonable to put them all in one repo, and save yourself the trouble of cloning all of them from 20 repos. Keeping each one in a separate repo seems like the path of creating a problem where a problem ...


13

TL;DR; the equivalent of a git repository is a CVS module, not a CVS repository. CVS is designed with a notion of modules being a subdivision of a repository, and it is common to use CVS repositories with several modules having a quite independent life. As an example, it is easy to have branches specific to one module and not present in another. git has ...


13

You should create a new repo for each independent project. Why? Someone working on project D does not have to download all the history for E and F. Git repos are cheap to initialize, so you can use as many as you like. It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly ...


11

Repository returns domain objects and is built on top of mapping layers. For a very simple domain domain objects and database tables can be very much the same. If your repository is always returning exact representation of your data structure then it might actually be Table Data Gateway aka Data Access Object(DAO). Example: Your database has tables for ...


11

Realistically, you've got three alternatives if you want deferred execution: Do it this way - expose an IQueryable. Implement a structure that exposes specific methods for specific filters or "questions". (GetCustomersInAlaskaWithChildren, below) Implement a structure that exposes a strongly-typed filter/sort/page API and builds the IQueryable internally. ...


11

Short answer ... Start out with the repositories in your personal account. From there, if/when things grow and/or get popular with the community, move them to an organization account. GitHub Blog: Repository redirects are here! Long answer ... Let's look at some of your options: 1. Organization: For more information on GitHub Organization features, ...


10

At my company, we use a separate SVN repository for every component of the system. I can tell you that it gets extremely frustrating. Our build process has so many layers of abstraction. We do this with Java, so we have a heavy build process with javac compilation, JibX binding compilation, XML validation, etc. For your site, it may not be a big deal if ...


9

I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice: Make small commits often. When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit ...


9

Unit tests don't catch all defects. But they are cheaper to set up and (re)run compared that other kinds of tests. The unit tests are justified by combination of moderate value and low-to-moderate cost. Here's a table showing defect detection rates for different kinds of testing. source: p.470 in Code Complete 2 by McConnell


8

As noted, svn log will get you this answer. But this really isn't suitable for time tracking -- just about all accounting systems need a hole for restatement, editing a svn commit description can be tricky if not impossible due to post-commit hooks. You might want to look at something like redmine which integrates with SVN and has a time tracking feature ...


8

I think you should think who has an interest to change that respective class. For example if you have an User class with an CalculatePay method and a save method. The accountant would want to change the CalculatePay and the DB administrator the save method. These are two different responsibilities. The SRP means grouping together things that change for the ...


8

No, they are not bad. Hopefully, one should have unit and integration tests. They are used and run at different stages in the development cycle. Unit Tests Unit tests should be run on the build server and locally, after the code has been compiled. If any unit tests fail, one should fail the build or not commit the code update until the tests are fixed. ...


7

Well, nowadays with the third generation of Source control, it's not that hard to start using them specially git or mercurial, I cannot think on any downside of why you should not use any of them. Also If you do not want to set a remote environment you can use sites like Github, bitbucket, CodeGoogle to keep your source up, and grab it whenever you want. I ...


7

Re: "UOW tracks the elements that needs be changed, and repository contains the logic to persist those changes, but... who call who?" You understand the basic responsibilities of these classes. You say that each of the articles, that you've read, connects them together in different ways. This implies that the decision about "who calls who" is up to you. ...


7

You want the version of the tests to match the version of the code, so that implies you keep the tests in the same repository as the code. That goes for automatic code generation scripts, build scripts, etc. too.



Only top voted, non community-wiki answers of a minimum length are eligible