Git Product home page Git Product logo

resume-maker's People

Contributors

sherfin94 avatar

Watchers

 avatar  avatar

resume-maker's Issues

Improvement - how to better segregate method tests

Have a look at these tests. All these are tests pertaining a single method. The first test is actually not needed and the second redundantly checks the final result. Here's a better way to rewrite the same:

describe "#to_hash" do
  it 'returns a hash with name, age, place' do
    the_hash = user.to_hash

    expect(the_hash).to eq({name: 'Some Name', age: '21', place: 'Some Place'})
  end
end

As a convention, when testing methods, have all the individual tests wrapped in a describe block as above. If the method is an instance method, let the description be the method name preceded by a hash # (e.g. describe "#to_hash"). If it were a class method, let the preceding symbol be a period . (e.g. describe ".my_class_method").

Test suite not correctly written

When we write tests, we don't usually check whether an instance of a class responds to a particular method. Instead, we check whether that method behaves correctly given various situations/scenarios. Your tests should ensure that in the event of code changes, the original functionality is still intact (these are what we call regression tests - just a fancy term).

Let's look at the tests written for the plugin handler and the resume maker. I can change the internal implementation of the methods and the tests wouldn't catch the changes.

Let me know if you need help understanding this more.

Unnecessary parent class?

The parent class for plugins is empty. Which means that it is not really needed there in the first place. I'm not suggesting that you get rid of it. What I'm saying is that in its current form, that class does not serve any specific purpose. Here's a small exercise for you - check out the template pattern. That might help you identify what that class should do.

Avoiding the case block

As a brainstorming exercise, can you try figuring out if there's any way you can avoid using the case block here?

Usually the switch-case block is regarded as unclean code. I don't quite agree with that. What I do think is that the tendency is generally to misuse it and hence it ends up getting used in inappropriate places. I think your current use of it is fine. But like I mentioned, as an exercise, just think about other means through which you can implement the same (no need to update the code or anything).

Act, arrange, assert - better organisation of your tests

When writing a test, there are generally 3 parts - arrange, act, assert.

  • Arrange refers to the setup necessary for the test happens - setting up objects, assigning values, etc.
  • Act is the actual action - the main line that produces the effect the test is checking.
  • Assert refers to the 'test' part, where you're checking the output of the action and the desired result.

Keep these sections separated by a space.

Let's have a look at one of the tests you've written. Right now, all the lines are not separated in any way. Here's how to space them apart according to the scheme I've mentioned above:

it 'returns a hash with name, age, place when called to_hash' do
  the_hash = user.to_hash

  expect(the_hash).to be_a(Hash)
  expect(the_hash).to eq({name: 'Some Name', age: '21', place: 'Some Place'})
end

Unnecessary usage of attr_accessor

In the resume maker, there are attribute accessors specified for the handlers. But if you really look at it, these are not details that need to be exposed outside this object. One of the ideas of OOP is encapsulation - keep internal stuff internal.

Method invocation not tested comprehensively

Let's take a look at this spec. It tests a method whose sole responsibility is to invoke another method. But the test does not check that part of it. I can change the method to return 1 at the end no matter what and the tests would still pass. A simple fix here can take care of that. There are a couple of other places where this has happened. I think this example should help you figure the rest out.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.