How do you manage your PHPUnit files in your projects?
Do you add it to your git repository or do you ignore them?
Do you use @assert tag in your PHPdocs codes?
How do you manage your PHPUnit files in your projects? Do you add it
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Setup
I’m not using php currently, but I’m working with python unit testing and sphinx documentation in git. We add our tests to git and even have certain requirements on test passing for pushing to the remote
develandmasterbranches (masterharder thandevel). This assures a bit of code quality (test coverage should also be evaluated, but thats not implemented yet :)).We have the test files in a separate directory next to the top-level source directory in the directories where they belong to, prefixed with
test_, so that the unit testing framework finds them automagically.For documentation its similar, we just put the sphinx docs files into their own subdirectory (docs), which is in our case an independent git submodule, which might be changed in the future.
Rationale
We want to be able to track changes in the tests, as they should be rare. Frequent changes indicate immature code.
Other team members need access to the tests, otherwise they’re useless. If they change code in some places, they must be able to verify it doesn’t break anything.
Documentation belongs to the code. In case of python, the code directly contains the documentation. So we have to keep it both together, as the docs are generated from the code.
Having the tests and the docs in the repository allows for automated testing and doc building on the remote server, which gives us instantaneous updated documentation and testing feedback. Also the implementation of “code quality” restrictions based on test results works that way (its actually more a reminder for people to run tests, as code quality cannot be checked with tests without looking at test coverage too). Refs are rejected by the git server if tests do not pass.
We for example require that on
master, all tests have to pass or be skipped (sadly, we need skipped, as some tests require OpenGL, which is not available on headless), while ondevelits okay if tests just “behave like expected” (i.e. pass, skip or expected failure, no unexpected success, error or failure).