Cy create language

[jemayn]

Remaking #11307 to get around a GH bug that showed way more changes.

@madsrasmussen If I add the TS definitions like they are in tests/Umbraco.Tests.AcceptanceTest/cypress/typings.d.ts I get intellisense and it all works 🙂

We could use that alongside adding the commands to the commands.js file we get typed custom commands, which can then once in a while be pulled into @bergmania 's package.

[umbrabot]

Hi there @jemayn, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[Zeegaan]

Found a few things that needs changing 👍

[Zeegaan]

Suggested change

	cy.umbracoEnsureLanguageNotExists(culture);
	cy.umbracoEnsureLanguageNameNotExists(culture);

Use the already existing language method

[Zeegaan]

Suggested change

	cy.umbracoEnsureLanguageNotExists(language1);
	cy.umbracoEnsureLanguageNotExists(language2);
	cy.umbracoEnsureLanguageNameNotExists(language1);
	cy.umbracoEnsureLanguageNameNotExists(language2);

[Zeegaan]

As mentioned in your other PR we already have a method called cy.umbracoEnsureLanguageNameNotExists(name)

Suggested change

	namespace Cypress {
	interface Chainable<Subject> {
	/**
	* Checks to see if the language with specified name does not exist
	* If it does it will automatically delete it
	* @param {string} name Name of language to delete
	* @example cy.umbracoEnsureLanguageNotExists('Danish');
	*/
	umbracoEnsureLanguageNotExists: (name: string) => Chainable<void>;
	namespace Cypress {
	interface Chainable<Subject> {

[jemayn]

@Zeegaan

The existing command matches on the language name, not the culture like this one. I've updated the method on this PR to make it clearer that it's on culture 🙂

[elit0451]

Just FYI: The just merged PR #11527 already moved the languages.ts to the tests folder, instead of src. 🙂
So make sure to get the latest changes from umbraco:v9/contrib.

[mikecp]

Hello @jemayn ,

Thanks for this PR, it's a nice addition to the acceptance tests suite 😉👍

It all works good, but before merging, I wanted to check with you, in the line of @Zeegaan 's remarks earlier, if there was a specific reason why you needed to add the method umbracoEnsureLanguageCultureNotExists and could not use the existing one umbracoEnsureLanguageNameNotExists.

I just want to make sure that we do not create what seems to be an "almost duplicate" method if there is no specific reason, but maybe I am overseeing something. 😁

Thanks in advance for your feedback!

[jemayn]

Hello @jemayn ,

Thanks for this PR, it's a nice addition to the acceptance tests suite 😉👍

It all works good, but before merging, I wanted to check with you, in the line of @Zeegaan 's remarks earlier, if there was a specific reason why you needed to add the method umbracoEnsureLanguageCultureNotExists and could not use the existing one umbracoEnsureLanguageNameNotExists.

I just want to make sure that we do not create what seems to be an "almost duplicate" method if there is no specific reason, but maybe I am overseeing something. 😁

Thanks in advance for your feedback!

Hey @mikecp !

I can amend the PR to use the existing method if you want, but I felt this was a better method than the existing one - the existing one relies on the language names which can be anything, this method uses the culture which is still just a string - but feels a bit safer to use..

[mikecp]

Hi @jemayn ,

Thanks for clearing the difference out, looking on a culture name seems indeed safer, so let's keep that method in there 😉!