Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added module-2 solution #47

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+33 −2
Open

added module-2 solution #47

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 33 additions & 2 deletions module-2/test/calc.spec.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,37 @@ describe.only('calc', () => {
* .minus(3)
* .times(6).v // 24
*/
// TODO: write test cases to test calculator

describe('v', () => {
it('should return positive value when positive number', () => expect(calc(3).v).equal(3))
it('should return negative value when negative number', () => expect(calc(-3).v).equal(-3))
})
describe('add', () => {
it('should return 8 when adding 3 and 5', () => expect(calc(3).add(5).v).equal(8))
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I skipped the.to.be part to minimize unnecessary boilerplate code, cause here the .to.be would not really increase readability.
Is it a bad practice? How is it used more in practice? (skipped or the .to.be and similar chain getters are just always there?)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, skipping the fillers does not affect the assertion itself, but still, in practice, we use them to be a bit more human-like and easy to adopt.
In some simple cases, this is not too talkative at all, but from a consistency perspective, I would suggest to use them.

it('should return -2 when adding 3 and -5', () => expect(calc(3).add(-5).v).equal(-2))
it('should return -8 when adding -3 and -5', () => expect(calc(-3).add(-5).v).equal(-8))
})
describe('minus', () => {
it('should return 1 when subtracting 3 and 2', () => expect(calc(3).minus(2).v).equal(1))
it('should return 5 when subtracting 3 and -2', () => expect(calc(3).minus(-2).v).equal(5))
it('should return -1 when subtracting -3 and -2', () => expect(calc(-3).minus(-2).v).equal(-1))
})
describe('sqrt', () => {
it('should preform sqrt', () => expect(calc(4).sqrt().v).equal(2))
it('should throw error for negative squared root', () => expect(() => calc(-3).sqrt()).throw('Square root of negative value cannot be determined!'))
})
describe('times', () => {
it('should return 30 when multiplying 3 and 10', () => expect(calc(3).times(10).v).equal(30))
it('should return -30 when multiplying 3 and -10', () => expect(calc(3).times(-10).v).equal(-30))
it('should return 30 when multiplying -3 and -10', () => expect(calc(-3).times(-10).v).equal(30))
})
describe('divide', () => {
it('should return 5 when dividing 10 and 2', () => expect(calc(10).divide(2).v).equal(5))
it('should return -5 when dividing 10 and -2', () => expect(calc(10).divide(-2).v).equal(-5))
it('should return 5 when dividing -10 and -2', () => expect(calc(-10).divide(-2).v).equal(5))
it('should throw error when dividing by zero', () => expect(() => calc(5).divide(0)).throw('Division by 0 is not possible!'))
})
describe('modulo', () => {
it('should return the remainder', () => expect(calc(10).modulo(5).v).equal(0))
})
it('should perform chained operations', () => expect(calc(3).add(4).minus(3).times(6).v).equal(24))
});