# Empirical Study of Test Case and Test Framework Presence in Public Projects on GitHub
## 3 Results
### Typical Number of \"test\" Occurrences  
Figure 2 shows the number of occurrences of the word \"test\" in all projects analyzed via the Github API. Zero occurrences were skipped to make the graph more readable. It is possible to see that in _all files content_ the typical number of occurrences of the word \"test\" was 4, in other search types it was 2.  
Manual investigation of results of 600 randomly selected projects (100 for each search type) with typical numbers of \"test\" occurrences can be seen in Figure 3. In all search types a high incidence of _example tests_ (58% occurrences of 600 manually analyzed projects), that are mostly generated by IDE or framework, was observed. They do not test the application functionality; therefore, they are not considered as real executable tests because they are not actually executed, e.g., in CI/CD. Example tests mostly occurred in Android projects with classes ExampleUnitTest, ExampleInstrumentedTest, or ApplicationTest. For non-Android projects, there were mostly test cases implemented as skeleton methods.  
Figure 3: Usage proportion of the word “test” by file type in projects with 4 occurrences for search in all files content and 2 occurrences in other searches.  
Figure 2: The number of occurrences of the word “test” for all Java primary language projects at GitHub.  
The second most common place of finding the word \"test\" was the _testing_ code, which is the main objective we search for. As can be seen, only a small portion of occurrences represent such tests. This means that the peak values of \"test\" occurrence are mostly caused by automatically generated tests and not by actual tests of the production code.  
The \"test\" string was also used in the _production code_ for  
* project's package name,
* identifiers, where \"test\" denotes \"examine\" or \"validate\" something,
* debugging or logging.  
Although some occurrences in the production code were used to verify application functionality, they were intended for manual testing or debugging of the code. As these were not automated tests, such occurrences were included in the production code group. Presence in _configuration_ files was high for _all files content_ search due to files such as pom.xml or gradle.build, where the testing process was mostly configured, e.g., testing directories, framework, etc. Other places of finding were _documentation_ (e.g., readme files, JavaDoc, comments), _test helpers_ (e.g., abstract testing class), or _other files_ (data, SQL dumps, images, dynamically generated content, etc.).  
**RQ 1**_Is there a typical number of the word \"test\" occurrences across a project that is observed in a large number of projects? If so, what is the reason behind such specific number?_  
Yes, the most frequent occurrence of the word \"test\" is 4 for _all files content_ search and 2 for _filename_, _path_, and _java files content_ search. A manual investigation of randomly selected repositories showed that 58% of such search results were _example test cases_, which are mostly responsible for such typical occurrences in projects. For _all files content_ search, there was the most occurred combination of two _example tests_ and two _configuration files_. Test cases were found in 11% of all results and 9% occurred in production code.