codeuino / codeuino/codebadge-backend

Write Unit Tests for CodeBadge

オープン
#18 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る
gci QA
主要言語
Vue
スター
15
フォーク
23
PR マージ指標
30日以内にマージされた PR はありません

説明

### **What you will need to know?**
Any Unit testing framework for JavaScript - Beginner/Intermediate level

### **Write Unit Tests for CodeBadge**
We can never be doubly sure of our code without automating the unit tests which check the sanity of the code. Although, BDD shall be the preferred coding approach, here we'll have to follow TDD approach. Thus, you'll have to write unit tests for each function used inside every **.js** file. For this, although you can use any famous Unit Testing framework for JavaScript, but recommended framework is [Mocha](https://mochajs.org/), along with [Chai](https://www.chaijs.com/) as it's assertion library. The sanity checks and testing logic shall b well taken care of since passing of unit tests will only decise, whether or not code is to be merged into `master`.
All tests shall pass and code coverage should be **>=80%**. The test coverage report can be generated using [Istanbul](https://istanbul.js.org/) library.

### **Requirements**
* Any Unit testing framework for JavaScript - Beginner/Intermediate level

### **Steps to Follow**
* Claim this issue: Comment below. If someone else has claimed it, ask if they've opened a pull request already and if they're stuck -- maybe you can help them solve a problem or move it along!
* Install CodeBadge on your system go through [readme.md]() in development branch for this purpose
* After installing CodeBadge install dependencies of backend and frontend, go through [readme.md]() inside both the folders
Link to readme https://github.com/codeuino/Codebadge/blob/master/README.md
* To run the project follow the given step in [readme.md]() for both frontend and backend.
* Checkout to a different feature branch in git and start with the coding part.
* Make sure to commit your work daily and create a single PR for all your commits, per feature.

### **Acceptance Criteria**
* Code is short, clean and properly indented.
* Unused code/comments/variables should not be lying in the code unnecessarily exploiting memory.
* Minimal number of re-iterations in order to improve efficiency and keep the commit history clean.
* Best practices should be used in case of multiple approaches, mentors are always there to help you for this 👍

### **Rejection Criteria**
* Not following/Violating [Code of Conduct](https://github.com/codeuino/Codebadge/blob/master/CODE_OF_CONDUCT.md) can lead to rejection.
* Coding etiquettes must be taken care of, for eg, always committing code in a different feature branch, same PR is edited in case of re-iteration of code, etc.

### **Expected Outcome**
A directory named as `/test` should be created in the root directory which will include all the .js test files. Each test should be named same as the name of file for which tests are written along with suffixing `-spec` in the filename. For eg, test file for signup.js should be named as signup-spec.js.

### **How to excel fast in the community?**
- Share the issues you encounter along the way and help others solve theirs.
- Chime in below in a comment to cooperate with others who are also working on this task.
- Report back at the above issue once you succeed, to encourage others and share what worked for you!

### **Resources & References (Where to Start)**
You'll need to go through the docs of [Mocha](https://mochajs.org/) framework, along with [Chai](https://www.chaijs.com/) as the assertion library to be used. [Istanbul](https://istanbul.js.org/) can be used for test coverage reporting.

### **Extras**
Just follow the readme whenever you are stuck . Visit [Codeuino's Website](https://codeuino.slack.com/) in case of any doubts.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

root README と backend/frontend README ファイルから始め、カバレッジが必要な JavaScript ファイルを一覧化します。提案されている Mocha、Chai、Istanbul のワークフローを設定し、対応するファイルを /test 配下に作成します。すべてのテストがパスし、カバレッジが 80% 以上になれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
javascript
領域
backend, testing
issue の種類
リファクタリング
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。