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

The .csv file in what the test are based must be in the slave inside the JMeter bin folder /bin/data/yourFile.csv

I agree that performance tests cannot be unit tests but there is no reason we cannot have another set of tests called performance tests. Broadly the tests fall under two categories a) Unit tests b) Integration tests We run integration tests again the real database (instead of in memory) to ensure the sql scripts, the hibernate repositories work as expected My idea is we can add another set of tests called performance tests which are a part of nightly build which tests for performance of certain functions. This is important to track down the statistics after a code re factoring or to evaluate if changes to one part of application can have unintended consequence on another. I have come across JunitPerf which might help me to achieve this objective.

To remove the attribute disabled="" you can use the following line of code: driver.execute_script("arguments[0].removeAttribute('disabled')", element)