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

Proposal cleaning #247

Merged
merged 34 commits into from
Jan 13, 2015
Merged

Proposal cleaning #247

merged 34 commits into from
Jan 13, 2015

Conversation

jreidinger
Copy link
Member

not yet ready for merge, need real testing and also automatic tests. More for discussion of design.

def self.run
new.run

# values used in defined functions
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like all this initializations ended in the wrong place after code shuffling (self.run instead of initialize)

Copy link
Member Author

Choose a reason for hiding this comment

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

good catch, my fault.

@ancorgs
Copy link
Contributor

ancorgs commented Dec 3, 2014

As always when refactoring without tests, I'm quite afraid of slippering bugs in. In general I like the reorganization into ProposalRunner and ProposalStore. Looks much better than before, even if I lack a clear full picture to give a good judgement.

@jreidinger
Copy link
Member Author

@ancorgs I plan to do manual and also write automatic tests, I just want at first discuss design, as it can change whole structure and require test rewrite.

@jreidinger
Copy link
Member Author

added some fixes after manual testing, automatic tests will follow


it "runs" do
# TODO: just catch exceptions
expect(subject.run).to eq :abort
Copy link
Member

Choose a reason for hiding this comment

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

Huh, why should a plain run return :abort? I would expect :next.

What do you mean by "just catch exceptions"? Is it "the code does whatever, but does not raise an exception?".

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, it is trivial test that there is no syntax or nil error. :abort because some parts are not set and it quit quickly.

Copy link
Contributor

Choose a reason for hiding this comment

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

So "runs" is obviously not a enlightening description.

Copy link
Member Author

Choose a reason for hiding this comment

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

ok, maybe "not crash" is better. Runner is quite tricky and not easy to test, so I just add basic test that there is no trivial error.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, it is perfectly fine to have such a test, only it should be phrased slightly differently IMHO:

it "passes a smoke test" do
  expect { subject.run }.to_not raise_error
end

A "smoke test" is a term from electronics: you solder a device, power it on, and nothing happens. No smoke comes out :)

Copy link
Member Author

Choose a reason for hiding this comment

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

@mvidner good idea, I will change it this way.

@jreidinger
Copy link
Member Author

@mvidner your suggestion implemented



tabs = properties["proposal_tabs"]
@tab_labels = tabs.map { |m| m["label"] || "Tab" }
Copy link
Member

Choose a reason for hiding this comment

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

That element is compulsory, remove || "Tab"

@mvidner
Copy link
Member

mvidner commented Jan 9, 2015

Overall, this is a partial clean-up of a big piece of code. Therefore, it is important to know what is in scope. For me, it was describing the shorter one of the new classes, ProposalStore, regarding its responsibilities and the interface of its public methods.

@jreidinger
Copy link
Member Author

@mvidner I fixed most of issues, except ones I comment. Maybe next time regarding documentation it will be faster if you directly commit to branch

@mvidner
Copy link
Member

mvidner commented Jan 13, 2015

Thank you!
Before merging, don't forget a .changes entry. I suggest

Refactored inst_proposal into Installation::ProposalRunner and Installation::ProposalStore.

I see you have made a nice conflict with your own Rubocop changes... hope most can be autocorrected.

@mvidner
Copy link
Member

mvidner commented Jan 13, 2015

LGTM now :)

@jreidinger
Copy link
Member Author

@mvidner thanks for very exhausting review 👍

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

3 participants