I have the following timeline:
=== 2016-02-19 ===
15:07:30 [61c9483b55] *CURRENT* ...
08:41:52 [6a8317cb5b] ...
=== 2016-02-18 ===
16:14:27 [469c4301dd] ...
15:59:42 [e0fb6a50c0] ...
15:58:15 [161561b17d] ...
=== 2016-02-11 ===
16:23:13 [770f95b9e4] ...
15:31:35 [a4c6f00a23] ...
14:59:15 [7ea7e751da] ...
14:57:13 [3adb8e5b4f] ...
11:59:13 [24558955aa] ...
=== 2016-02-05 ===
15:50:20 [7a760541b0] ...
10:27:18 [6630ce2f8c] ...
09:51:32 [d146724770] ...
=== 2016-01-29 ===
13:20:48 [4a30407708] ...
08:09:54 [e29b22f7e2] ...
--- line limit (20) reached ---
During the revision 7a760541b0 and 24558955aa a bug has been introduced, which I want to fix by reverting the change. But I do not want to revert to the version 24558955aa, because after that many good changes have been made.
How can I undo just those changes done by 24558955aa?
What you're looking for is a subfeature of fossil merge. Backing out a change is basically the inverse of cherrypicking this change and indicated by the --backout option, e.g.:
fossil merge --backout 24558955aa
You will still have to commit the new revision after the merge (and, ideally, should review the code to verify that the bug has indeed been undone). Note that conflicts may arise (because of other changes that happened in the meantime); these can be resolved in the usual fashion.
Related
I am very new to playwright and i have a problem.
I am trying to implement comparing two screenshots (before and after) in one test.
this is what i want to achieve:
navigate to webpage
take screenshot (before.png)
do some stuff,state changes, etc
take screenshot (after.png)
compare before.png to after.png (if they are the same test should pass, otherwise test fails)
something like this:
test('compare screenshots', async ({ page }) => {
await page.goto('my website here');
const beforeImage = await page.screenshot({
path: `./screenshots/before.png`
})
//
// some state changes implemented here
//
const afterImage = await page.screenshot({
path: `./screenshots/after.png`
})
expect(beforeImage).toMatchSnapshot(afterImage)
});
but it does not work like this.
Any ideas/suggestions how can i achieve this?
Help would be greatly appreciated
You can do something like this:
test('compare screenshots', async ({ page }, testInfo)=>{
await page.goto(pageUrl);
const screenshotTarget = page.locator(scTarget);
await expect(screenshotTarget).toHaveScreenshot( `${testInfo.title}.png`);
//
// some state changes implemented here
//
await expect(screenshotTarget).toHaveScreenshot( `${testInfo.title}.png`);
});
I prefer to use the test titel for naming my screenshots but it should also work if you just enter the same name twice. Then if you run your tests without --update-snapshots they should fail if some visual changes happened.
The problem with Playwright's toHaveScreenshot and toMatchSnapshot is that they're a bit over-engineered and will only compare a current screenshot to a screenshot from a previous test run. If you want to compare two screenshots that you have as Buffers in memory, you can use the getComparator method that Playwright uses behind the scenes:
import { getComparator } from 'playwright-core/lib/utils';
await page.goto('my website here');
const beforeImage = await page.screenshot({
path: `./screenshots/before.png`
});
//
// some state changes implemented here
//
const afterImage = await page.screenshot({
path: `./screenshots/after.png`
});
const comparator = getComparator('image/png');
expect(comparator(beforeImage, afterImage)).toBeNull();
The advantage of using getComparator is that it fuzzy matches, and you can set the threshold of how many pixels are allowed to be different. If you just want to check that the PNGs are exactly identical, a dead simple method to check for equality between the two screenshots is:
expect(Buffer.compare(beforeImage, afterImage)).toEqual(0)
Beware though - this simpler method is flakey and sensitive to a single pixel difference in rendering (such as if any animations/transitions are not completed or if there are differences in anti-aliasing).
So I have two values on a page that I need to compare and as per the result perform some actions.
//First Block
cy.get('selctor1').invoke('text').then(somevalue => {
cy.get('selector2').should('have.text', somevalue).then(() => {
#Do Something when equal
})
})
//Second Block
cy.get('selctor1').invoke('text').then(somevalue => {
cy.get('selector2').should('not.have.text', somevalue).then(() => {
#Do Something when not equal
})
})
So for the positive case when both values are equal everything works fine. But for the case when two values are not equal, it's only checking the first block and fails. What should I do so that it executes the second block when values are not equal and not the first block?
Sorry for not being clear the first time. Here is my edited answer:
Then vs Should:
Try to avoid then where possible. then is not repeatable and will introduce unexpected behaviour.
But also will should introduce unexpeced behaviour.
Example for a bad usage of then:
describe("asd", () => {
it("fails but retries", () =>{
console.log("######### first test")
cy.wrap({ fn: () => console.log(new Date())})
.invoke("fn")
.should(r => expect(r).to.eq(true));
})
it("fails but retries not", () =>{
console.log("######### next test")
cy.wrap({ fn: () => console.log(new Date())})
.invoke("fn")
.then(r => {
expect(r).to.eq(true)
});
})
})
In this example you see the same code twice but the first block uses should while the second block uses then. The assertion must fail but in the first block, the assertion is repeated. Open the DEV COnsole to see many retries for the first block but no retry in the second.
This is what I mean by "unexpected" behaviour. Let's say, you wrap a object that is dynamically extended (maybe by a UI action) and you are expecting a property on this object. In the second block (then) the UI acton must be executed very fast and before thethenis executed so that theexpect` does not fail.
In the should case, you have 4 seconds (in case of `defaultCommandTimeout is not overwritten) left until the assert will finally fail.
Bad usage of should:
describe("ad", () => {
it("test", () => {
cy.visit("https://www.cypress.io/")
cy.get("*[aria-label='pricing']")
.invoke('text').should(someValue => {
cy.get("asdad", {timeout: 5000}).should("not.exist");
})
})
})
What would you expect? A green test? No, this test fails:
Why is this the case? Because get introduces an implicit assert "should exist" (see: https://docs.cypress.io/guides/core-concepts/introduction-to-cypress.html#Default-Assertions ).
Should with callback skips the default assertion (see: https://docs.cypress.io/api/commands/should.html#Notes ).I think they skip it by toggling it by flag. This could have the effect of reversing the flag again and thus forces cypress to check if "asdad" does exist even though we use should not exist.
There is an issue for this stuff: https://github.com/cypress-io/cypress/issues/5963
I do not know why cy.log has the behaviour you mentioned in your case. So either you use then if you want to use cy commands within then callback or you avoid the usage of cy commands and use should with explicit assertions (expect). Maybe after that issue is fixed, cy.log also can be used.
Old Answer:
cy.get('selctor1').invoke('text').should(someValue => {
const $el = Cypress.$('selector2');
if ($el.text() ==== someValue) {
// positive
expect()....
} else {
// negative
expect()....
}
})
You can use should with a callback. This callback (and the previous invoke command) is executed as long as the timeout is reached or no assertion fails.
You always can use the raw jQuery object to work with. This depends on whether or not you need all the checks cypress is executing during a get().
Please let me know if you need further assistance.
How could I get the name / version of the next migration to execute? Something similar to migrations:latest but more like migrations:next. I need this as input to another command so it needs to be parseable output (can't really just use migrations:status).
You can use the Configuration object of the Doctrine migrations bundle. This is even (somewhat) documented as custom configuration.
Here is a minimal code example that works for me:
public function migrationVersionAction(EntityManagerInterface $em, ParameterBagInterface $parameters) {
$connection = $em->getConnection();
$configuration = new \Doctrine\Migrations\Configuration\Configuration($connection);
$configuration->setMigrationsNamespace($parameters->get('doctrine_migrations.namespace'));
$configuration->setMigrationsDirectory($parameters->get('doctrine_migrations.dir_name'));
$configuration->setMigrationsTableName($parameters->get('doctrine_migrations.table_name'));
return new JsonResponse([
'prev' => $configuration->resolveVersionAlias('prev'),
'current' => $configuration->resolveVersionAlias('current'),
'next' => $configuration->resolveVersionAlias('next'),
'latest' => $configuration->resolveVersionAlias('latest')
]);
}
You might want to set the remaining parameters as well though, especially if they differ from the defaults. For this, the configuration documentation might help in addition to the link above.
I'm trying to remove a field from a changeset (or set it to undefined) so that when the changeset is applied the field will be removed (or set to undefined) on the model. How can this be achieved?
Cheers
ember-changeset does not support setting a value to undefined. Calling changeset.set() with undefined as value does not set the value.
let obj = Ember.Object.create({
foo: 'a',
bar: 'b'
});
let changeset = new Changeset(user);
changeset.set('foo', null);
changeset.set('bar', undefined);
changeset.get('bar'); // b
changeset.get('change'); // { foo: null }
I'm quite surprised about that myself. Since it's not expected behavior and it does not seem to be documented, I think it should be considered a bug and get fixed.
I've opened a pull request for ember-changeset adding a failing test: https://github.com/DockYard/ember-changeset/pull/191
I have a property mood which is part of the interface for a component. Behind the scenes I have a computed property called _mood:
const { computed, typeOf } = Ember;
_mood: computed('mood','A','B','C' function() {
let mood = this.get('mood');
if (typeOf(mood) === 'function') {
mood = mood(this);
}
return !mood || mood === 'default' ? '' : `mood-${mood}`;
}).volatile(),
I have a situation where with the volatile() that hangs of of Ember's computed object resolves all non DOM unit tests successfully but for some reason it is not triggering the template to update the DOM under any circumstance. It should, at the very least, update if any of properties being watched change (in this case ['mood','A', 'B', 'C']) change. Because it is volatile (aka, doesn't cache results) the new results would show up in a template if the template knew to re-render the component but for some reason it doesn't.
If I remove the volatile() tag it works fine for static/scalar values but if mood is a function then the result is cached and therefore it only works once (not a working solution for this problem).
How do I get the best of both worlds?
I'm still not sure why the volatile() method is turning off updates to templates. This might be a real bug but in terms of solving my problem the important thing to recognise was that the volatile approach was never the best approach.
Instead the important thing to ensure is that when mood comes in as a function that the function's dependencies are included in the CP's dependencies. So, for instance, if mood is passed the following function:
mood: function(context) {
return context.title === 'Monkeys' ? 'happy' : 'sad';
}
For this function to evaluate effectively -- and more importantly to trigger a re-evaluation at the right time -- the title property must be part of the computed property. Hopefully that's straight forward as to why but here's how I thought I might accommodated this:
_moodDependencies: ['title','subHeading','style'],
_mood: computed('mood','size','_moodDependencies', function() {
let mood = this.get('mood');
console.log('mood is: %o', mood);
if (typeOf(mood) === 'function') {
run( ()=> {
mood = mood(this);
});
}
return !mood || mood === 'default' ? '' : `mood-${mood}`;
}),
That's better, as it allows at build time for a static set of properties to be defined per component (the _mood CP for me is part of a mixin used by a few components). Unfortunately this doesn't yet work completely as the it apparently doesn't unpack/destructure the _moodDependencies.
I'll get this sorted and update this unless someone else beats me to the punch.