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.

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

Unit tests for logic/vote #26

Merged
merged 7 commits into from Oct 27, 2017
Merged

Unit tests for logic/vote #26

merged 7 commits into from Oct 27, 2017

Conversation

jarenal
Copy link
Member

@jarenal jarenal commented Oct 13, 2017

Test ready for review! Some test will fail until I fix some little issues that I found in logic/vote

Copy link
Contributor

@vekexasia vekexasia left a comment

Choose a reason for hiding this comment

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

Please remove all "..." texts on it. I think the other texts don't have that

@jarenal
Copy link
Member Author

jarenal commented Oct 13, 2017

Done! '...' Removed

Copy link
Contributor

@nerdvibe nerdvibe left a comment

Choose a reason for hiding this comment

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

@jarenal Thanks a lot for your code, it's really appreciated!
I've made some notes about your code.

Some things that I would recommend you:

  • Use semi columns. There are no semi columns in the code.
  • Avoid to make a function call for every variable that you need to get from the original file. Always try to cache locally as much data as you can :)
  • Try to follow code patterns/stylings. I'm my opinion the whole code should look like it has been written only by only one person. E.g. I would avoid to use contexts if they have not been used it also before.

I'd also recommend you to setup prettier and use it with webstorm. It's an 💥 combination that will style your code in an awesome way.


describe('logger and schema should be setted properly into library', function () {
it('should be an object', function () {
expect(Vote.__get__('library').logger).to.equals(logger)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you could get library at the beginning of the "it" and check then in every expect what you need to expect.
In this way you your code will look a bit better and be a bit more performant :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Done!

})
})

describe('when we call to...', function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

I see here a different pattern in writing tests. I believe we should agree on something.
Roman's pattern (which is the one that I'm following) is to not wrap all the methods inside another wrapper that is inside another wrapper like in this case.

I'd reccomend to follow his pattern:

describe('logic/vote', function () {

  describe('constructor', function () {
      it('test', ..)
      it('test', ..)
      it('test', ..)
  })

  describe('method', function () {
      it('test', ..)
      it('test', ..)
      it('test', ..)
    })

  describe('method2', function () {
      it('test', ..)
      it('test', ..)
      it('test', ..)
    })
})

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree, Lets stick with the later pattern.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done!


it('delegates, rounds and system should be setted properly into modules variable', function () {
vote.bind(delegates, rounds, system)
expect(Vote.__get__('modules').delegates).to.equals(delegates)
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd recommend to call get only once :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes 👍 it also improves code readability.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done!


it('should return vote\'s fee', function () {
vote.bind(delegates, rounds, system)
var fee = vote.calculateFee(trs, sender, height)
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd recommend to stub calculateFees and check if it's called.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm? you mean removing this test entirely? I would actually keep it @xunga

Copy link
Member Author

Choose a reason for hiding this comment

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

No modifications were done


context('if trs.recipientId and trs.senderId are not equals', function () {

beforeEach(function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is more a question from my side. Do we really need a beforeEach and afterEach when we have only one test case? In my opinion I would put the logic directly into the it. Maybe this is not a correct approach, I would like to get an opinion on this :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Well test cases should only test behavioural stuff. all init and teardown should be kept separate as much as you can.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done!

context('if everything is ok', function () {
it('should return an object with votes as property in Array format', function () {
var result = vote.dbRead(raw_success)
expect(result).to.have.deep.property('votes')
Copy link
Contributor

Choose a reason for hiding this comment

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

I think that the next expect is enough, or?

Copy link
Member Author

Choose a reason for hiding this comment

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

I added the second one for to verify that the values received are correct.



})

Copy link
Contributor

Choose a reason for hiding this comment

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

Test of dbTable and dbFields are missing...

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think that to test a static object is within the testing standards. What do you think guys?

trs = {id: 123, asset: {votes: [1, 2, 3]}}
})

it('should return an object with a valid db schema', function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

I would say that expect(result).to.instanceof(Object) is useless and I would also test what happens if trs.asset.votes is not an array...

Copy link
Member Author

Choose a reason for hiding this comment

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

Done!

beforeEach(function () {
trs = {}
trs_case_4 = {signatures: [1, 2, 3]}
trs_case_4_b = {signatures: [1, 2]}
Copy link
Contributor

Choose a reason for hiding this comment

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

Same of before, no need of this code in here :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Done!

})
})

context('Fail 5: If v_votes is not a string', function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

This test is failing

Copy link
Member Author

Choose a reason for hiding this comment

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

Depends on issue #31


it('delegates, rounds and system should be setted properly into modules variable', function () {
vote.bind(delegates, rounds, system)
expect(Vote.__get__('modules').delegates).to.equals(delegates)
Copy link
Contributor

Choose a reason for hiding this comment

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

Yes 👍 it also improves code readability.


it('should return vote\'s fee', function () {
vote.bind(delegates, rounds, system)
var fee = vote.calculateFee(trs, sender, height)
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm? you mean removing this test entirely? I would actually keep it @xunga


context('if trs.recipientId and trs.senderId are not equals', function () {

beforeEach(function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

Well test cases should only test behavioural stuff. all init and teardown should be kept separate as much as you can.


beforeEach(function () {
clock = sinon.useFakeTimers()
Vote.__set__('setImmediate', setImmediate)
Copy link
Contributor

Choose a reason for hiding this comment

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

I see that you use context instead of sub describe while it's a safe guard we shouldn't misuse contexts especially if they're not really used.

Also it would be better to have one beforeEach and afterEach where you sinon.useFakeTimers and also do other shared stuff between tests (like the setImmediate thing?)

Right now there is a lot of boilerplate involving the init/teardown of test groups.

clock.restore()
})

it('should call to callback without errors', function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

sender = {address: 123}
block = {id: 123, height: 123}
Vote.__set__('setImmediate', setImmediate)
Vote.__set__('self.checkConfirmedDelegates', function (trs, cb) {
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

clock.restore()
})

it('should call to callback', function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

The test says should call callback and tests that. If there's a need to check the parent.scope.account then another test (probably above this one) needs to be written

it('should call to scope.account.merge() and callback()', function () {
clock.runAll()
var result = Vote.__get__('self.scope')
expect(result.account.merge.called).to.be.true
Copy link
Contributor

Choose a reason for hiding this comment

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

agree

@coveralls
Copy link

Coverage Status

Coverage increased (+4.4%) to 59.389% when pulling 694b166 on unit-test-logic-vote into 5f23a12 on development.

@jarenal
Copy link
Member Author

jarenal commented Oct 27, 2017

This PR is failing because depends on these issues #31 and #43

@vekexasia vekexasia merged commit 8966c11 into development Oct 27, 2017
@vekexasia vekexasia deleted the unit-test-logic-vote branch October 27, 2017 15:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants