TDD – Full Stack QE https://fullstackqe.org Just another WordPress site Sun, 24 May 2020 18:49:14 +0000 en-US hourly 1 https://wordpress.org/?v=6.1.6 155680629 Can TDD Apply To Performance Testing? https://fullstackqe.org/can-tdd-apply-to-performance-testing/ Sun, 24 May 2020 18:48:24 +0000 https://fullstackqe.org/?p=330 Continue reading "Can TDD Apply To Performance Testing?"

]]>
Neotys explained in a simple way how we can do Performance Testing early in the cycle and how can we minimize the risk and costs.

Test-Driven Development is a great tool for functional testing, but can you apply the same technique to performance testing?

Why not?

The purpose of TDD is to build out small unit tests, or scenarios, under which you control your initial coding. Your tests will fail the first time you run them because you haven’t actually developed any code. But once you do start coding, you’ll end up with just enough code to pass the test.

Some Tricks for Performance TDD:

1. Create small-batch load tests that can stress small components. As you start planning your module, think about how that module would be stressed. What algorithms are most likely to limit scalability? Is there an opportunity for resource contention? Do you have queries that could impact performance if they get too large or complicated? Then create your test scenarios specifically to stress the component in these ways. As you and your team work through more and more of the product, you’ll end up building an amazing library of load test scenarios that you can leverage in lots of interesting ways moving forward.

2. Don’t apply TDD to optimizations, instead just use it for base-level performance. The job of a performance engineer is often focused on optimizing code that’s already been written by someone. TDD isn’t really going to be much help here. Remember, TDD is best leveraged at the beginning of the code-writing process. So that’s where you should start. As your product matures, it’s completely appropriate to make your load tests incrementally more demanding (a certain function must return in 2 seconds instead of 4 seconds), but that may not always be the ideal place to focus because scaling problems are often driven by more complex interactions that are best suited for different kinds of test methodologies.

3. Automate. TDD and automation go hand-in-hand, and you should approach it that way from the beginning. Think about how to automate your TDD from the moment you start doing it, like any modern development method. By doing this, you’ll be able to easily plug your performance testing into other automated processes like continuous integration, but you’ll also end up with a number of micro-load test scenarios that can be strung together into a larger automated test scenario. This gives you a ton of leverage.

Article Source

]]>
330