The error message cy.type() can only accept a string or number. You passed in: undefined says the last part of the path is undefined, e.g this.data.fullName or this.info.userGoodCredit.company. If this.data was undefined, you error would be cannot get property "fullName" of undefined, so your beforeEach() is probably ok. It looks like there's a typo in the property used in the test, or in the fixture object. Check with console.log(this.info.userGoodCredit) and console.log(this.data).

I think the condition attribute is missing: - task: PublishTestResults@2 inputs: failTaskOnFailedTests: false testRunner: VSTest testResultsFiles: '**/*.trx' searchFolder: '$(Build.Repository.LocalPath)' condition: succeededOrFailed() From the documentation: In this YAML, PublishTestResults@2 will run even if the previous step fails because of the succeededOrFailed()

I would say that is the lowest possible severity, but that might vary depending on the rules of your team or some specifics about the app. For example, a factor that might make that a high severity bug is when font colors are part of a brand or something like national flag colors or similar where changing colors might significantly change the user perception of the app. Another example is accessibility and readability. Some colors might not work with other colors on the page so changing them might alter usability of the app for certain categories of users.

You would have to load all your data into objects from the fixtures, but you could then add each response to an array and shift each time inside a while loop. Your error reporting won’t be great but you should be able to process all of your data sets with minimal code duplication. Something like this, maybe: it(‘tests my data sets’, () => { const datasets = [dataset1, dataset2, dataset3]; while(dataset.length > 0) { cy.intercept('GET', '/todos', req => req.reply(datasets.shift())); cy.get(‘items’).should(‘be.visible’); } });

Some prefer to use HttpClient because it is already built into the framework. So there's no need to add extra bloat to your project. RestSharp, like any library, is easier to use because someone already did the hard work and ironed out the problems gotten along the way. I have used both, and the one is not better than the another. It just depends on your use-case, situation and environment. I had a WebAPI proxy project that needed to call another REST API. I chose RestSharp at first because I was already familiar with it from using it in another project. However, I changed to HttpClient eventually because it uses the same return types as the WebAPI controllers, so it just saved me time from having to convert RestSharp's responses back to a HttpResponseMessage. Of course each one has its pros and cons, it just boils down to your use-case.

use @BeforeMethod and @AfterMethod as following: public class DemoTest { private static final Logger log = LoggerFactory.getLogger(DemoTest.class); @BeforeMethod public void before() { log.info("before"); } @AfterMethod public void after() { log.info("after"); } @Test public void test1() { log.info("test1"); } @Test public void test2() { log.info("test2"); } } result: before test1 after before test2 after

Not only the server need to be able to respond fast enough, JMeter must be able to send requests fast enough as well. Default JMeter configuration is suitable for tests development and debugging and creating some load (rather limited though), you need to properly tune your JMeter instance in order to fully utilize your machine resources If your single machine is not powerful enough to conduct the required load it's possible to run JMeter in distributed mode using as many load generators as needed in order to create the necessary number of virtual users/requests per second

let jsonData = pm.response.json(); pm.environment.set("test_name", jsonData.test3[0].id3); test3 is an array so you have to get the first object and then id3

The where clause is redundant. You can just add all to a single query: select count(column1), count(column2), . . . count(column20) from t