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

Create tests for `vessel-charging/messages/VesselStatusMessageParams` using jest. #30

Open
haialaluf opened this Issue Sep 5, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@haialaluf
Member

haialaluf commented Sep 5, 2018

first-timers-only

This issue is tagged :octocat: first-timers-only. It is only for people who have never contributed to open source before, and are looking for an easy way take their first steps.

Consider this your chance to dip your toe into the world of open-source, and get some bragging rights for writing code that makes drones fly, lets cars find charging stations, helps people and goods get from place to place, and more.

Find more first-timers-only issues from DAV Foundation here.

Thank you for your help ❤️

What is this project?

DAV (Decentralized Autonomous Vehicles) is a new foundation working to build an open-source infrastructure for autonomous vehicles (cars, drones, trucks, robots, and all the service providers around them) to communicate and transact with each other over blockchain.

As an organization that believes in building a large community of open-source contributors, we often create issues like this one to help people take their first few steps into the world of open source.

dav-js

This SDK enabled integrating any client side JS and NodeJS code with the DAV Network.

How you can help

The Issue

Create tests for vessel-charging/messages/VesselStatusMessageParams using jest.

You need to create tests to check that the serialize and deserialize methods work as expected.

Please use the test file for class NeedParams as a basis for your new code.

  • Function serialize in class MessageParams must return a JSON object that contains all properties defined in the MessageParams instance.

  • Function deserialize in class MessageParams receives a JSON string and must initialize all the properties of the MessageParams instance with the values in the JSON string.

messageParams1.desrialize(messageParams2.serialize()) == messageParams2 must therefore always be true.

NOTE: Some names are changed between protocol string representation of instance properties:

  • location is internally represented as { lat , lon } but serialized as { latitude , longitude }
  • Private properties are internally prefixed with _ but serialized without the prefix. i.e. _protocol becomes protocol

Contributing to dav-js

  • Make sure this issue is labeled up-for-grabs and not labeled claimed, to verify no one else is working on it.
  • Comment in this issue that you would like to do it.
  • Open dav-js GitHub page and click the ★ Star and then ⑂ Fork buttons.
  • Clone a copy to your local machine with $ git clone git@github.com:YOUR-GITHUB-USER-NAME/dav-js.git
  • Code Code Code
  • Once you've made sure all your changes work correctly and committed all your changes, push your local changes back to github with $ git push -u origin master
  • Visit your fork on GitHub.com (https://github.com/YOUR-USER-NAME/dav-js) and create a pull request for your changes.
  • Make sure your pull request describes exactly what you changed and references this issue (include the issue number in the title like this: #7)
  • Please do not fix more than one issue at a time. Your pull request should only fix what is described in this issue.

Asking for help

We appreciate your effort in taking the time to work on this issue and help out the open source community and the foundation. If you need any help, feel free to ask below or in our gitter channel. We are always happy to help 😄

@ericcgu

This comment has been minimized.

Show comment
Hide comment
@ericcgu

ericcgu Sep 13, 2018

Hello team! My name is Eric. I am an experienced developer but have never contributed to open source. I would like to help if possible.

I reviewed the sample code (https://github.com/DAVFoundation/dav-js/blob/master/src/vessel-charging/NeedParams.test.ts).

The question I have is this:

Is there a specific reason for using Jest Matcher expect(object1).toEqual(object2)?

Typically, toEqual is too coupled with implementation for testing objects and makes for a brittle test. If we add n+1 properties to object1 class, we need to update the test. I feel that this will cause slowdowns in development because the assertion is too narrow, causing the test to be too brittle.

The idea I had was to use expect(object1).toMatch(object2) and including a few key properties, which may make for better faster testing, sans development slowdown and achieve the same benefit.

https://jestjs.io/docs/en/expect#tomatchobjectobject

ericcgu commented Sep 13, 2018

Hello team! My name is Eric. I am an experienced developer but have never contributed to open source. I would like to help if possible.

I reviewed the sample code (https://github.com/DAVFoundation/dav-js/blob/master/src/vessel-charging/NeedParams.test.ts).

The question I have is this:

Is there a specific reason for using Jest Matcher expect(object1).toEqual(object2)?

Typically, toEqual is too coupled with implementation for testing objects and makes for a brittle test. If we add n+1 properties to object1 class, we need to update the test. I feel that this will cause slowdowns in development because the assertion is too narrow, causing the test to be too brittle.

The idea I had was to use expect(object1).toMatch(object2) and including a few key properties, which may make for better faster testing, sans development slowdown and achieve the same benefit.

https://jestjs.io/docs/en/expect#tomatchobjectobject

@TalAter

This comment has been minimized.

Show comment
Hide comment
@TalAter

TalAter Sep 13, 2018

Member

Thank you @ericcgu

That's a very good observation. I had to take some time to consider it, but I think I prefer the current implementation using toEqual()

The test for the serializer makes sure that a certain input always gives a certain predictable output. And both the expected input and output are present in the test code. If in the future we change how the serialization works (e.g., by adding not just ttl but also a ttl_expiry_logging_endpoint), the change should be reflected in the test.

Yes, it's a change that might happen in the parent NeedParams and then affect the vessel-charging NeedParams test, and so could be argued to be too coupled. But I like how the expected outcome of the function is explicitly stated here. Makes the test read like documentation.

Anyway, as I already said, that is an excellent observation. We would be honored to have your expertise and help you get started on your path to more involvement with open source. Open source has had a tremendous influence on my career (success and enjoyment)... it's a path worth taking.

Member

TalAter commented Sep 13, 2018

Thank you @ericcgu

That's a very good observation. I had to take some time to consider it, but I think I prefer the current implementation using toEqual()

The test for the serializer makes sure that a certain input always gives a certain predictable output. And both the expected input and output are present in the test code. If in the future we change how the serialization works (e.g., by adding not just ttl but also a ttl_expiry_logging_endpoint), the change should be reflected in the test.

Yes, it's a change that might happen in the parent NeedParams and then affect the vessel-charging NeedParams test, and so could be argued to be too coupled. But I like how the expected outcome of the function is explicitly stated here. Makes the test read like documentation.

Anyway, as I already said, that is an excellent observation. We would be honored to have your expertise and help you get started on your path to more involvement with open source. Open source has had a tremendous influence on my career (success and enjoyment)... it's a path worth taking.

@ericcgu

This comment has been minimized.

Show comment
Hide comment
@ericcgu

ericcgu commented Sep 13, 2018

Thank you @TalAter .

@TalAter

This comment has been minimized.

Show comment
Hide comment
@TalAter

TalAter Sep 18, 2018

Member

@ericcgu I believe there is a bug in all the message files for vessel-charging which will cause you to not be able to complete this issue.

Would you be interested in tackling another one? Perhaps #22

This is for a decentralized ride hailing app we are currently building, it's a cool one.

Member

TalAter commented Sep 18, 2018

@ericcgu I believe there is a bug in all the message files for vessel-charging which will cause you to not be able to complete this issue.

Would you be interested in tackling another one? Perhaps #22

This is for a decentralized ride hailing app we are currently building, it's a cool one.

@ericcgu

This comment has been minimized.

Show comment
Hide comment
@ericcgu

ericcgu Sep 19, 2018

Yes please.

ericcgu commented Sep 19, 2018

Yes please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment