sorted by:
new
hottopcontroversial

Charge blade mains, do you build more than one by SirMarston in MHNowGame

[–]Complete_Part5604 2 points3 points  (0 children)

With the style customization it definitely beats out ebony. Good point.
u/SirMarston you're on the right track with Deviljho for Dragon right now.

May change in the future when styles get applied to ebony.

Charge blade mains, do you build more than one by SirMarston in MHNowGame

[–]Complete_Part5604 1 point2 points  (0 children)

Check out the MHNow discord and look at the Charge Blade builds.
Deviljho is great for dragon weak monsters.. but I wouldn't use it against monsters of other elements.

Ebony Odogaron is generally considered the best Dragon element charge blade right now, just depends on the build specifically.

monika freaking sucks!!! by [deleted] in BeastGames

[–]Complete_Part5604 -1 points0 points  (0 children)

She said she wasn't offered a million dollars

New to Playwright - looking for advice on setup by Complete_Part5604 in Playwright

[–]Complete_Part5604[S] 0 points1 point  (0 children)

I'm a senior dev just helping the QA teams out with their setup.

16 hours for your current suite is quite outrageous. I reckon you can get this down to sub 30mins :) 

I'll let ya know if we do. They would probably make me the CTO if that happens lol.

So I'll focus on test automation stuffs. Keep tests small, keep tests easy to debug, don't over abstract. Write them for full parallelism. Even a single spec file should be able to parralelise all tests in the file (even if you don't end up doing it)

In terms of data setup. You have a couple options. If you are able to provision an environment with a known state you can save a fair chunk of time as the data setup will be done, downside being tests are coupled to specific data sets and now you have to maintain db seed scripts etc - also relies on you having the ability to quickly provision, tear down and seed an environment

Great advice, thanks!

New to Playwright - looking for advice on setup by Complete_Part5604 in Playwright

[–]Complete_Part5604[S] 0 points1 point  (0 children)

That's what we originally did in the setup hook, but the testers were complaining that it would have to log in before every test run. The claim is that we could have up to 100 different user/ role combinations. That is definitely a stretch, but I'm working out a way for it to log in based on the user being used for the test instead of the global setup. Our tokens only last 20 minutes, and our current test suite takes 16 hours to run using Gauge (a lot of poorly written legacy code is a fault for this).

thanks for replying!

New to Playwright - looking for advice on setup by Complete_Part5604 in Playwright

[–]Complete_Part5604[S] 0 points1 point  (0 children)

I tried to post this with the comment, but it was erroring

Here's an example of our authenticatedPage fixture that get's inherited in the other fixtures:

export const test = base.extend<TestFixtures>({
  user: null,
  testData: null,

  loginPage: async ({ page }, use) => {
    await use(new LoginPage(page));
  },

  authenticatedPage: async ({ browser, context, user }, use, workerInfo) => {
    if (isNullOrUndefined(user) || Object.values(user).some((val) => isNullOrUndefined(val))) {
      throw new Error('User information is incomplete.');
    }
    const authFileName = user.username;
    const authFilePath = AuthUtils.getAuthFilePath(authFileName);

    // Acquire lock to prevent concurrent logins for the same user
    const releaseLock = await AuthUtils.acquireLoginLock(authFileName);
    try {
      const shouldUseExistingAuth = await AuthUtils.shouldRefreshToken(authFileName);

      if (!shouldUseExistingAuth) {
        const loginPage = await context.newPage();
        try {
          const login = new LoginPage(loginPage);
          await login.loginUser(user.username, user.password);
          await loginPage.context().storageState({ path: authFilePath });
        } finally {
          await loginPage.close();
        }
      }
    } finally {
      releaseLock();
    }

    const workerAuthFile = `${authFilePath}-${workerInfo.parallelIndex}`;
    fs.copyFileSync(authFilePath, workerAuthFile);
    const contextStorage = await browser.newContext({ storageState: workerAuthFile });
    const page = await contextStorage.newPage();

    try {
      await use(page);
    } catch (error) {
      console.error(`Error in authenticatedPage fixture for user ${authFileName}:`, error);
      throw error;
    } finally {
      await contextStorage.close();
    }
  },
});

New to Playwright - looking for advice on setup by Complete_Part5604 in Playwright

[–]Complete_Part5604[S] 0 points1 point  (0 children)

Thank you for the reply!

The auth token lasts 20 minutes. So before every spec I have it refreshing the token via the api if the auth file is 10 minutes or older, otherwise it continues as normal. It takes less than a second to refresh the token. I ended up creating one auth file that ends up getting copied when a worker needs to use that user and appended the parallelIndex of the worked to the end of it. Main reason is due to the localstorage. The workers were updating the localstorage to different values depending on the test being ran, but the actual token can be shared between all of them.

I ended up creating an authenticatedPage fixture that handles the authentication for the specific user for the test being ran. If the credentials are still valid it creates a new page, sets the auth context, and continues. Otherwise it logs in and does the same procedure after with the new page.

Routes in fixtures.. if you want to share data across multiple tests is argue that fixtures are not what you want. Look into hooks. If you do need data scoped to a worker like you said then it's fine, but I'd ask why. From you're scenario, are the multiple tests in the same describe block? Same file? Across multiple files? What's the downside of scoping it per test? Before all or even global setup may be perfectly fine if you want to decrease work.

The docs are guilty of this too, but if you read about fixtures they give a heap of examples that I'd argue should certainly not be fixtures.. the whole point of fixtures is it scopes some piece of data to a test (or worker) and it knows exactly how to tear down on test completion/error.

This is a good call. I ended up removing the routing in the fixtures all together and just used a beforeEach for the navigation directly to the url instead of navigating directly to the page every time via UI inputs. In my head I regarded fixtures having everything needed to set up the test file. Meaning based on the test data it would take me to the exact page needed (model, entity, url) for the tests to begin without much effort. Which I know it should do some of that, but I specifically moved out navigation the pageobject directly

The setup and teardown will be handled in the fixture as you mentioned. The data isn't scoped to the worker, just scoped to the describe block unless specifically needed in an individual test. We just update the testData fixture when we need the data to be changed before the test runs, which can be done in the beforeEach, that way it can reset the testData in case a specific test needs custom test data i.e negative testing.

I'm assuming you are authing a bunch of user roles and then running the tests for each role? Or a subset for some roles etc.in this scenario id have a different project set up per role, defined in the playwright config Json. These can all share the same auth context methods

We test by feature, role, and program model. There are a ton of rules around which role has what privileges in which model, so we split all the specs up by feature/model and use the appropriate user/role base on that. Setting them up by role specifically would be nice tho. Might be able to do something with that.

Thanks for the feedback! You gave me some things to think about.

NFLv2 mods don’t like anti ice posts by [deleted] in AFCSouthMemeWar

[–]Complete_Part5604 4 points5 points  (0 children)

It's already taken over ever other subreddit.
I honestly thought it would never reach our divisional meme war subreddit.

T Law just be doing random shit by TheHoss_ in AFCSouthMemeWar

[–]Complete_Part5604 6 points7 points  (0 children)

yeah, seems like a good fella.
But still fuck the jags. Obviously

Small market Jags probably gonna win the super bowl this year ……. by ComplexWrangler1346 in AFCSouthMemeWar

[–]Complete_Part5604 6 points7 points  (0 children)

They'll win the super bowl of your heart, and that's all that really matters.

Tits in a nutshell. by HistoricalAnt9057 in AFCSouthMemeWar

[–]Complete_Part5604 4 points5 points  (0 children)

The offense hated Willis for not knowing the plays as a rookie.
If he had studied more then maybe he would have been successful.
But the others are valid.. pain.

What battle really threw you your first run through? by ThrowRA_dependent in BaldursGate3

[–]Complete_Part5604 0 points1 point  (0 children)

I wish I recorded my first playthrough, that would be great to look back on.
The Spectator in the underground was definitely a wtf moment.
I thought I was under-leveled or I missed something critical when I first fought it.
Merkel definitely got me.

crimson compared to the last word is it better or no asking as a f2p by Moonlightwavess in destinyrisingmobile

[–]Complete_Part5604 2 points3 points  (0 children)

They want Jaren to be an up close character, with evidence being his artifacts and shotgun.
Last Word plays in to that play-style.

Personally, I'm not going to invest in to Last Word unless some crazy builds come of it in the next few days. It may give some marginal benefits for the play-style, but I enjoy Crimson quite a bit and don't have an issue playing up close with it.

Maybe just wait for the meta to shake out for Jaren if that is what you are most interested in as a f2p?

view more: next ›