- Tip 0: Why should you open-source your project?
- Tip 1: Don’t rush features, Code quality matters
- Tip 2: Test, test and test again
- Tip 3: Have a sexy README
- Tip 4: Document your project
- Tip 5: Release the right way
- Tip 6: Get feedbacks
- Tip 7: Promote
- Tip 8: Handle the issues
- Tip 9: Listen to your issues
- Tip 10: Don’t merge every pull requests
Test, test and test again
Testing is an important part of the process of software engineering. And while it is already important in a professional environment, it is even more important in an open-source context.
First, it makes you feel confident that your library is working as it should. In the same way you want to avoid bugs in production, you do want to avoid that for your open-source project. It is especially true for that kind of project because people will not necessarily report it when they encounter a bug: they might think this is an expected behavior, an un-supported feature or simply stop using your project (slowing down your project adoption if you want it to be used).
Second, if you want people to use your project, they will look for alternatives, then choose what is the most appropriate solution. They will base their choice on different factors: features, size, popularity, … But basically, for two libraries with equivalent features, what will make the difference is whether the person feel confident into including your project into their project. And to be confident, they are looking at whether your library is stable, widely used and tested.
Third, not providing tests decreases your maintainability or will undoubtedly lead to regressions at some points.
Last, but not least: you make it harder to contribute to your project. When people want to contribute, they usually use part of your project and just want to improve a specific behavior or fix a bug. Only you knows how your entire project works and you must not assume that others will. Contributors will simply code the stuff they need and might break other existing components without noticing it. And you might not even notice it during the code review.
I know tests are boring and no one wants to code them, but do it to avoid the worst. And again, you don’t have any deadlines except the ones you defined, so take some time and don’t rush for features: test them first.
Additionally, I advise you to setup an integration server that automatically compile you project (if necessary) and run you test whenever you push new code to the repository and whenever someone opens a pull request.
I personally use Travis, but there are plenty of alternatives such as Jenkins, Circle or Shippable. Most of them are SaaS, entirely free if your project is open-sourced, easy to setup, with a nice UI and extremely useful: why not using them?
Read next tip: Tip 3: Have a sexy README
Subscribe via RSS