├── .github └── ISSUE_TEMPLATE │ ├── bug_report.md │ └── feature_request.md ├── .gitignore ├── .idea ├── codeStyles │ └── Project.xml ├── encodings.xml ├── gradle.xml ├── misc.xml ├── runConfigurations.xml └── vcs.xml ├── AS.PNG ├── CODE-OF-CONDUCT.md ├── CONTRIBUTING.md ├── PULL_REQUEST_TEMPLATE.md ├── app ├── .gitignore ├── build.gradle ├── proguard-rules.pro └── src │ ├── androidTest │ └── java │ │ └── com │ │ └── anjan │ │ └── mockitounittesttutorial │ │ └── ExampleInstrumentedTest.java │ ├── main │ ├── AndroidManifest.xml │ ├── java │ │ └── com │ │ │ └── anjan │ │ │ └── mockitounittesttutorial │ │ │ ├── Cache.java │ │ │ ├── EmailService.java │ │ │ ├── InitialContext.java │ │ │ ├── Locator.java │ │ │ ├── LocatorService.java │ │ │ ├── MainActivity.java │ │ │ ├── MessagingService.java │ │ │ ├── Point.java │ │ │ ├── SMSService.java │ │ │ ├── ServiceLocator.java │ │ │ ├── Utils.java │ │ │ ├── async │ │ │ ├── DummyCallback.java │ │ │ ├── DummyCaller.java │ │ │ ├── DummyCollaborator.java │ │ │ └── db │ │ │ │ ├── CustomerDao.java │ │ │ │ ├── EntityManager.java │ │ │ │ └── Logger.java │ │ │ ├── contributor │ │ │ └── ContributorActivity.java │ │ │ ├── exercise │ │ │ ├── UpdateUsernameUseCaseSync.java │ │ │ ├── description.txt │ │ │ ├── eventbus │ │ │ │ ├── EventBusPoster.java │ │ │ │ └── UserDetailsChangedEvent.java │ │ │ ├── networking │ │ │ │ ├── NetworkErrorException.java │ │ │ │ └── UpdateUsernameHttpEndpointSync.java │ │ │ └── users │ │ │ │ ├── User.java │ │ │ │ └── UsersCache.java │ │ │ ├── mock │ │ │ ├── Customer.java │ │ │ ├── EmailSender.java │ │ │ ├── Event.java │ │ │ ├── EventRecorder.java │ │ │ ├── InvoiceStorage.java │ │ │ └── LateInvoiceNotifier.java │ │ │ ├── stub │ │ │ ├── Customer.java │ │ │ ├── CustomerReader.java │ │ │ └── DbManager.java │ │ │ └── sync │ │ │ ├── LoginUseCaseSync.java │ │ │ ├── authtoken │ │ │ └── AuthTokenCache.java │ │ │ ├── eventbus │ │ │ ├── EventBusPoster.java │ │ │ └── LoggedInEvent.java │ │ │ └── networking │ │ │ ├── LoginHttpEndpointSync.java │ │ │ └── NetworkErrorException.java │ └── res │ │ ├── drawable-v24 │ │ └── ic_launcher_foreground.xml │ │ ├── drawable │ │ └── ic_launcher_background.xml │ │ ├── layout │ │ └── activity_main.xml │ │ ├── mipmap-anydpi-v26 │ │ ├── ic_launcher.xml │ │ └── ic_launcher_round.xml │ │ ├── mipmap-hdpi │ │ ├── ic_launcher.png │ │ └── ic_launcher_round.png │ │ ├── mipmap-mdpi │ │ ├── ic_launcher.png │ │ └── ic_launcher_round.png │ │ ├── mipmap-xhdpi │ │ ├── ic_launcher.png │ │ └── ic_launcher_round.png │ │ ├── mipmap-xxhdpi │ │ ├── ic_launcher.png │ │ └── ic_launcher_round.png │ │ ├── mipmap-xxxhdpi │ │ ├── ic_launcher.png │ │ └── ic_launcher_round.png │ │ └── values │ │ ├── colors.xml │ │ ├── strings.xml │ │ └── styles.xml │ └── test │ └── java │ └── com │ └── anjan │ └── mockitounittesttutorial │ ├── LocatorTest.java │ ├── async │ ├── DummyCallerTest.java │ └── db │ │ └── CustomerDaoTest.java │ ├── mock │ └── LateInvoiceNotifierTest.java │ ├── stub │ └── CustomerReaderTest.java │ └── sync │ └── LoginUseCaseSyncTest.java ├── assets └── Unit test Documentation.pdf ├── build.gradle ├── doc ├── FOSS MileStone 2.pptx ├── FOSS Milestone 1.pptx └── Pull request and merge conflict with rebase.pdf ├── gradle.properties ├── gradle └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew ├── gradlew.bat ├── readme.md ├── settings.gradle └── slides ├── Unit test-1.pptx ├── Unit test-2.pptx └── Unit test-3.pptx /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | 11 | 12 | ## Description 13 | 14 | 15 | ## Expected Behavior 16 | 17 | 18 | ## Actual Behavior 19 | 20 | 21 | ## Possible Fix 22 | 23 | 24 | ## Steps to Reproduce 25 | 26 | 27 | 1. 28 | 2. 29 | 3. 30 | 4. 31 | 32 | ## Context 33 | 34 | 35 | ## Your Environment 36 | 37 | * App version used: 38 | * Device Name and version: 39 | * Operating System and version: 40 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | 11 | 12 | ## I'm submitting a ... 13 | 14 | - [ ] feature request 15 | - [ ] support request 16 | 17 | ## Expected Behavior 18 | 19 | 20 | ## Actual Behavior 21 | 22 | 23 | 24 | ## What is the motivation / use case for changing the behavior? 25 | 26 | 27 | 28 | ## Your Environment 29 | 30 | * App version used: 31 | * Device Name and version: 32 | * Operating System and version: 33 | 34 | 35 | * **Other information** (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc) 36 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Built application files 2 | *.apk 3 | *.ap_ 4 | *.aab 5 | 6 | # Files for the ART/Dalvik VM 7 | *.dex 8 | 9 | # Java class files 10 | *.class 11 | 12 | # Generated files 13 | bin/ 14 | gen/ 15 | out/ 16 | release/ 17 | 18 | # Gradle files 19 | .gradle/ 20 | build/ 21 | 22 | # Local configuration file (sdk path, etc) 23 | local.properties 24 | 25 | # Proguard folder generated by Eclipse 26 | proguard/ 27 | 28 | # Log Files 29 | *.log 30 | 31 | # Android Studio Navigation editor temp files 32 | .navigation/ 33 | 34 | # Android Studio captures folder 35 | captures/ 36 | 37 | # IntelliJ 38 | *.iml 39 | .idea/workspace.xml 40 | .idea/tasks.xml 41 | .idea/gradle.xml 42 | .idea/assetWizardSettings.xml 43 | .idea/dictionaries 44 | .idea/libraries 45 | # Android Studio 3 in .gitignore file. 46 | .idea/caches 47 | .idea/modules.xml 48 | # Comment next line if keeping position of elements in Navigation Editor is relevant for you 49 | .idea/navEditor.xml 50 | 51 | # Keystore files 52 | # Uncomment the following lines if you do not want to check your keystore files in. 53 | #*.jks 54 | #*.keystore 55 | 56 | # External native build folder generated in Android Studio 2.2 and later 57 | .externalNativeBuild 58 | 59 | # Google Services (e.g. APIs or Firebase) 60 | # google-services.json 61 | 62 | # Freeline 63 | freeline.py 64 | freeline/ 65 | freeline_project_description.json 66 | 67 | # fastlane 68 | fastlane/report.xml 69 | fastlane/Preview.html 70 | fastlane/screenshots 71 | fastlane/test_output 72 | fastlane/readme.md 73 | 74 | # Version control 75 | vcs.xml 76 | 77 | # lint 78 | lint/intermediates/ 79 | lint/generated/ 80 | lint/outputs/ 81 | lint/tmp/ 82 | # lint/reports/ 83 | -------------------------------------------------------------------------------- /.idea/codeStyles/Project.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | xmlns:android 14 | 15 | ^$ 16 | 17 | 18 | 19 |
20 |
21 | 22 | 23 | 24 | xmlns:.* 25 | 26 | ^$ 27 | 28 | 29 | BY_NAME 30 | 31 |
32 |
33 | 34 | 35 | 36 | .*:id 37 | 38 | http://schemas.android.com/apk/res/android 39 | 40 | 41 | 42 |
43 |
44 | 45 | 46 | 47 | .*:name 48 | 49 | http://schemas.android.com/apk/res/android 50 | 51 | 52 | 53 |
54 |
55 | 56 | 57 | 58 | name 59 | 60 | ^$ 61 | 62 | 63 | 64 |
65 |
66 | 67 | 68 | 69 | style 70 | 71 | ^$ 72 | 73 | 74 | 75 |
76 |
77 | 78 | 79 | 80 | .* 81 | 82 | ^$ 83 | 84 | 85 | BY_NAME 86 | 87 |
88 |
89 | 90 | 91 | 92 | .* 93 | 94 | http://schemas.android.com/apk/res/android 95 | 96 | 97 | ANDROID_ATTRIBUTE_ORDER 98 | 99 |
100 |
101 | 102 | 103 | 104 | .* 105 | 106 | .* 107 | 108 | 109 | BY_NAME 110 | 111 |
112 | 113 | 114 | 115 | 116 | -------------------------------------------------------------------------------- /.idea/encodings.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /.idea/gradle.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 20 | 21 | -------------------------------------------------------------------------------- /.idea/misc.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 17 | 27 | 28 | 29 | 30 | 31 | 32 | 34 | -------------------------------------------------------------------------------- /.idea/runConfigurations.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 11 | 12 | -------------------------------------------------------------------------------- /.idea/vcs.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /AS.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/anjandebnath/MockitoUnitTestTutorial/71c1c4ae93d0d9fbb5ddab80af6b96cf1c1a69ea/AS.PNG -------------------------------------------------------------------------------- /CODE-OF-CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies within all project spaces, and it also applies when 49 | an individual is representing the project or its community in public spaces. 50 | Examples of representing a project or community include using an official 51 | project e-mail address, posting via an official social media account, or acting 52 | as an appointed representative at an online or offline event. Representation of 53 | a project may be further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at [info@telemesh.net]. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | 73 | [homepage]: https://www.contributor-covenant.org 74 | 75 | For answers to common questions about this code of conduct, see 76 | https://www.contributor-covenant.org/faq 77 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | 4 | # Table of contents 5 | 1. [Introduction](#introduction) 6 | 2. [Community Code of Conduct](#codeofconduct) 7 | 1. [Be considerate](#beconsiderate) 8 | 2. [Be respectful](#berespectful) 9 | 3. [Be collaborative](#becollaborative) 10 | 4. [When you disagree, consult others](#disagree) 11 | 5. [When you're unsure, ask for help](#unsure) 12 | 6. [Step down considerately](#stepdown) 13 | 14 | 3. [Your First Contribution](#firstcontribution) 15 | 4. [Support questions](#supportquestions) 16 | 5. [Reporting issues](#reportissue) 17 | 6. [Fix Bugs](#fixbugs) 18 | 7. [Implement Features](#features) 19 | 8. [Submitting an Issue](#submitissue) 20 | 9. [Feature requests](#featurereq) 21 | 10. [Code review process](#codereview) 22 | 11. [Community](#community) 23 | 12. [Pull Requests](#pullreq) 24 | 1. [How to create PR](#howpullreq) 25 | 13. [Git Commit Guidelines](#gitcommit) 26 | 14. [Coding style guide](#codingstyle) 27 | 15. [Organize github issues](#organize) 28 | 16. [Issue Referencing on Github](#issuereference) 29 | 30 | 31 | 32 | ## Introduction 33 | 34 | First off, thank you for considering contributing to MockTest. It's people like you that make MockTest such a great tool. 35 | 36 | When contributing to this repository, please first discuss the change you wish to make via issue ticket ([sample](https://github.com/anjandebnath/MockitoUnitTestTutorial/issues/5)) with the owners of this repository before making a change. 37 | 38 | Please note we have a code of conduct, please follow it in all your interactions with the project. 39 | 40 | When contributing to MockTest, we ask that you: 41 | 42 | - let us know what you plan in the [GitHub Issue tracker](https://github.com/anjandebnath/MockitoUnitTestTutorial/projects/2) so we can provide feedback. 43 | 44 | - provide tests and documentation whenever possible. It is very unlikely that we will accept new features or functionality into MockTest without the proper testing and documentation. When fixing a bug, provide a failing test case that your patch solves. 45 | 46 | - open a GitHub Pull Request with your patches and we will review your contribution and respond as quickly as possible. Keep in mind that this is an open source project, and it may take us some time to get back to you. Your patience is very much appreciated. 47 | 48 | 49 | 50 | ## Community Code of Conduct 51 | 52 | 53 | The goal is to maintain a MockTest community that's pleasant for everyone. 54 | That's why we would greatly appreciate it if everyone contributing to and 55 | interacting with the community also followed this Code of Conduct. 56 | 57 | 58 | ### Be considerate 59 | 60 | 61 | Your work will be used by other people, and you in turn will depend on the 62 | work of others. Any decision you take will affect users and colleagues, and 63 | we expect you to take those consequences into account when making decisions. 64 | Even if it's not obvious at the time, our contributions to MockTest will impact 65 | the work of others. For example, changes to code, infrastructure, policy, 66 | documentation and translations during a release may negatively impact 67 | others work. 68 | 69 | ### Be respectful 70 | 71 | 72 | The MockTest community and its members treat one another with respect. Everyone 73 | can make a valuable contribution to MockTest. We may not always agree, but 74 | disagreement is no excuse for poor behavior and poor manners. We might all 75 | experience some frustration now and then, but we cannot allow that frustration 76 | to turn into a personal attack. It's important to remember that a community 77 | where people feel uncomfortable or threatened isn't a productive one. We 78 | expect members of the MockTest community to be respectful when dealing with 79 | other contributors as well as with people outside the MockTest project and with 80 | users of MockTest. 81 | 82 | ### Be collaborative 83 | 84 | 85 | Collaboration is central to MockTest and to the larger free software community. 86 | We should always be open to collaboration. Your work should be done 87 | transparently and patches from MockTest should be given back to the community 88 | when they're made, not just when the distribution releases. If you wish 89 | to work on new code for existing upstream projects, at least keep those 90 | projects informed of your ideas and progress. It many not be possible to 91 | get consensus from upstream, or even from your colleagues about the correct 92 | implementation for an idea, so don't feel obliged to have that agreement 93 | before you begin, but at least keep the outside world informed of your work, 94 | and publish your work in a way that allows outsiders to test, discuss, and 95 | contribute to your efforts. 96 | 97 | ### When you disagree, consult others 98 | 99 | 100 | Disagreements, both political and technical, happen all the time and 101 | the MockTest community is no exception. It's important that we resolve 102 | disagreements and differing views constructively and with the help of the 103 | community and community process. If you really want to go a different 104 | way, then we encourage you to make a derivative distribution or alternate 105 | set of packages that still build on the work we've done to utilize as common 106 | of a core as possible. 107 | 108 | ### When you're unsure, ask for help 109 | 110 | 111 | Nobody knows everything, and nobody is expected to be perfect. Asking 112 | questions avoids many problems down the road, and so questions are 113 | encouraged. Those who are asked questions should be responsive and helpful. 114 | However, when asking a question, care must be taken to do so in an appropriate 115 | forum. 116 | 117 | ### Step down considerately 118 | 119 | Developers on every project come and go and MockTest is no different. When you 120 | leave or disengage from the project, in whole or in part, we ask that you do 121 | so in a way that minimizes disruption to the project. This means you should 122 | tell people you're leaving and take the proper steps to ensure that others 123 | can pick up where you leave off. 124 | 125 | 126 | ## Your First Contribution 127 | 128 | Unsure where to begin contributing to MockTest? You can start by looking through these `good-first` and `help-wanted` issues: 129 | 130 | * [Good first issues](https://github.com/anjandebnath/MockitoUnitTestTutorial/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) - issues which should only require a few lines of code, and a test or two. 131 | * [Help wanted issues](https://github.com/anjandebnath/MockitoUnitTestTutorial/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) - issues which should be a bit more involved than `good-first` issues. 132 | 133 | Both issue lists are sorted by total number of comments. While not perfect, number of comments is a reasonable proxy for impact a given change will have. 134 | 135 | Working on your first Pull Request? You can learn how from this *free* series, [How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github). 136 | 137 | At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first :smile_cat: 138 | 139 | If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge. 140 | 141 | 142 | ## Support questions 143 | 144 | 145 | Please, don't use the issue tracker for this. Use one of the following 146 | resources for questions about your own code: 147 | 148 | * The ``#get-help`` channel on our [Discord chat](comming soon) 149 | 150 | * The mailing list media@MockTest.net for long term discussion or larger issues. 151 | 152 | 153 | ## Reporting issues 154 | 155 | Report bugs at https://github.com/anjandebnath/MockitoUnitTestTutorial/issues. 156 | 157 | We have different templates for bug report and feature request which you can find during issue creation. 158 | 159 | ```text 160 | 161 | 162 | 163 | ### Description 164 | 165 | 166 | ### Expected Behavior 167 | 168 | 169 | ### Actual Behavior 170 | 171 | 172 | ### Possible Fix 173 | 174 | 175 | ### Steps to Reproduce 176 | 177 | 178 | 1. 179 | 2. 180 | 3. 181 | 4. 182 | 183 | ### Context 184 | 185 | 186 | ### Your Environment 187 | 188 | * App version used: 189 | * Device Name and version: 190 | * Operating System and version: 191 | 192 | ``` 193 | 194 | 195 | ## Fix Bugs 196 | 197 | Look through the GitHub issues for bugs. Anything tagged with "bug" 198 | is open to whoever wants to implement it. 199 | [Sample issue](https://github.com/anjandebnath/MockitoUnitTestTutorial/issues/5) 200 | 201 | 202 | ## Implement Features 203 | 204 | 205 | Look through the GitHub issues for features. Anything tagged with "enhancement" 206 | and "optimization" is open to whoever wants to implement it. 207 | 208 | Please do not combine multiple feature enhancements into a single pull request. 209 | 210 | Note: We're trying to keep the code base 211 | small, extensible, and streamlined. Whenever possible, it's best to try and 212 | implement feature ideas as separate projects outside of the core codebase. 213 | 214 | 215 | 216 | ## Submitting an Issue 217 | 218 | Before you submit an issue, 219 | **search** the issues archive; 220 | maybe the issue has already been submitted or considered. If the issue appears to be a bug, 221 | and hasn't been reported, open a [new issue](https://github.com/anjandebnath/MockitoUnitTestTutorial/issues/new/choose). 222 | 223 | > Please **do not report duplicate issues**; help us maximize the effort we can spend fixing 224 | issues and adding enhancements. 225 | 226 | Providing the following information will increase the chances of your issue being dealt with 227 | quickly: 228 | 229 | * **Issue Title** - provide a concise issue title prefixed with a snake-case name of the 230 | associated service or component (if any): `: `. 231 | Adding the `md-` prefix should be avoided. 232 | 233 | > e.g. 234 | > * unit-test: mockito library syncing problem [#5](https://github.com/anjandebnath/MockitoUnitTestTutorial/issues/5) 235 | 236 | 237 | * **Complete the full Issue Template** - You will get the issue template where we put some predefined rules to create an issue. 238 | Moreover we are always open to make any changes according contributor's feedback. 239 | 240 | * **Suggest a Fix** - if you can't fix the bug yourself, perhaps you can point to what might be 241 | causing the problem (line of code or commit). 242 | 243 | #### Submitting Pull Requests 244 | 245 | **Important**: We are not accepting major feature requests or PRs that contain major new features 246 | or breaking changes at this time but we are welcoming to plan it for future or, we can discuss further offline. 247 | 248 | 249 | ## Feature requests 250 | 251 | If you find yourself wishing for a feature that doesn't exist in MockTest, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that MockTest has today have been added because our users saw the need. Open an issue on our issues list on GitHub which describes the feature you would like to see, why you need it, and how it should work. 252 | 253 | ## Code review process 254 | 255 | The core team looks at Pull Requests on a regular basis.Each code review should aim to achieve one or more of these goals; however, not all code reviews need to aim for all goals. 256 | 257 | Code review goals: 258 | 259 | - Finding bugs 260 | - Bugs found in code review require much less effort to find & fix than bugs found in QA/testing. 261 | - Coding style. Ensure that [Android coding standard](https://github.com/ustwo/android-coding-standards) and [Coding Pattern](https://blog.mindorks.com/android-code-style-and-guidelines-d5f80453d5c7) are followed. 262 | - Improving code quality 263 | - Teaching best practices 264 | - Code consistency (can't tell the author from the code) 265 | - Learning code 266 | - Efficiency (getting pull requests reviewed quickly) 267 | - Ensuring that the pull request guidelines are followed. 268 | 269 | 270 | Code review processes: 271 | 272 | - Issue a pull request with a full link to your ticket in the description. 273 | - Click the "Request Review" option on the ticket to move into the "Code Review (pre commit)" state. 274 | - Add a comment linking to your pull request by its url. 275 | 276 | Code review checklists : 277 | 278 | - Variable naming convention. 279 | - Method naming convention. 280 | - is the Class file is written in suitable package that is defined in guideline. 281 | - Override methods should be listed upper and then the private methods. 282 | - xml naming convention. 283 | - Layout design. 284 | - Unit test check. 285 | - Proper commenting on each method. 286 | - Method body and if any logical improvement is needed. 287 | - If any 3rd party library used then is it good to use or not 288 | - No sophisticated url access/data on git commit 289 | 290 | ## Community 291 | 292 | We will finalise our contributors community and list down their details soon 293 | 294 | ## Pull Requests 295 | 296 | Follow all instructions in [the template](https://github.com/anjandebnath/MockitoUnitTestTutorial/blob/master/PULL_REQUEST_TEMPLATE.md) 297 | The process described here has several goals: 298 | 299 | - Maintain MockTest's code quality 300 | - Fix problems that are important to users 301 | - Engage the community in working toward the best possible MockTest 302 | - Enable a sustainable system for MockTest's maintainers to review contributions 303 | 304 | ### How to create PR 305 | 306 | [How to create PR on Github](https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github) 307 | 308 | [How to update existing PR](https://www.digitalocean.com/community/tutorials/how-to-rebase-and-update-a-pull-request) 309 | 310 | 311 | ## Git Commit Guidelines 312 | 313 | We have very precise rules over how our git commit messages can be formatted. This leads to **more 314 | readable messages** that are easy to follow when looking through the **project history**. 315 | 316 | 317 | ### Commit Message Format 318 | Each commit message consists of a **header**, a **body** and a **footer**. The header has a special 319 | format that includes a **type**, a **scope** and a **subject**: 320 | 321 | ```html 322 | (): 323 | 324 | 325 | 326 |