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

[Admin] Tax category creation #4587

Merged
merged 8 commits into from
Mar 24, 2016

Conversation

lchrusciel
Copy link
Member

Q A
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Related tickets
License MIT
Doc PR

Based on #4573

@pjedrzejewski pjedrzejewski added the Admin AdminBundle related issues and PRs. label Mar 22, 2016
@lchrusciel lchrusciel force-pushed the tax-category-creation branch 11 times, most recently from c36e7b3 to e48838e Compare March 23, 2016 15:49
@pjedrzejewski
Copy link
Member

@lchrusciel Rebase needed.

@lchrusciel
Copy link
Member Author

on it

@lchrusciel
Copy link
Member Author

and done

@lchrusciel lchrusciel force-pushed the tax-category-creation branch 4 times, most recently from 7c42404 to e18d10b Compare March 24, 2016 10:01
function it_throws_an_exception_if_the_message_on_a_page_is_not_related_to_creation(NotificationAccessorInterface $notificationAccessor)
{
$notificationAccessor->hasSuccessMessage()->willReturn(true);
$notificationAccessor->isSuccessfullyCreatedFor('tax_category')->willReturn(false);
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not with ManagingTaxCategoryContext::RESOURCE_NAME ?

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'm not sure which approach is better. I'm not convinced about using const in specs. I just prefer to write it by my self, especially, because I do not have this const when I am writing first lines of spec

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes the specs highly vulnerable, as changing introducing a constant should happen for a reason - to keep the code DRY. It's just the same situation as with typehinting all the collaborators or using @mixin - the refactoring in most IDEs will understand it and prevent us from unnecessary, repetitive work.

As for a non-existing constant, it's nothing unusual while writing specs, as you also don't have the SUT or methods you are using on it :)

* @Then this tax category name should be :taxCategoryName
*/
public function thisTaxCategoryNameShouldBe($taxCategoryName)
{
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't we always assert that page is open before using it?

@lchrusciel lchrusciel force-pushed the tax-category-creation branch 2 times, most recently from fe41e5a to 3c3ff30 Compare March 24, 2016 12:39
{
use SpecifiesCode;
use NamesIt;
use DescribesItAs;
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's be consistent:

  • SpecifiesItsCode ❓
  • NamesIt 🆗
  • DescribesIt~~As~~

@michalmarcinkowski
Copy link
Contributor

@lchrusciel nice work! 👍

@pjedrzejewski pjedrzejewski merged commit 37ad7be into Sylius:master Mar 24, 2016
@pjedrzejewski
Copy link
Member

Perfect, thanks Łukasz!

@lchrusciel lchrusciel deleted the tax-category-creation branch March 24, 2016 22:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Admin AdminBundle related issues and PRs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants