TDD

How Test-Driven-Development works (Part 3)

This is part 3 of the blog series about how TDD (Test-Driven-Development) works. To start from the beginning you can refer to the start of the blog series here. We will continue our journey of TDD with the upcoming requirements to evolve our code along with the new tests. Requirement 4: Allow the Add method to handle an unknown amount of numbers [Java Test] Now we will refactor our code to implement the functionality of handling the sum of an unknown amount of numbers [Java Implementation] What we did is remove the existing functionality of handling the exception of more than two numbers. So after cleaning our code, our method will look as follows. Now when we rerun our tests all tests will pass as our requirement has been changed from handling only two numbers to handling an unknown amount of numbers. Requirement 5: Allow the Add method to handle newlines between numbers (instead of commas). [Java Test] [Java Implementation] To fulfill this requirement we just need to extend the split regex by adding |\n. Requirement 6: Support different delimiters In this requirement, it is specified that a user can use a different delimiter other than a comma which should also be accommodated by our String calculator. To specify the desired delimiter, it has to be at the beginning of the string that should look like this: “//[delimiter]\n[numbers…]” for example “//;\n4;6” should take 4 and 6 as parameters and return 10 where the default delimiter is “;”. [Java Test] [Java Implementation] For this requirement implementation, we did quite a lot of refactoring. We split the code into 2 methods. The initial method parses the input looking for the delimiter and later on calls the new private one that does the actual sum. Since we already have tests that cover all existing…

Continue Reading

TDD

How TDD (Test-Driven-Development) works (Part 2)

This is part 2 of the blog series about how TDD (Test-Driven-Development) works. You can refer to the start of the blog series here. We will continue with the next requirement to evolve our code for String Calculator. First, we will make the test fail for our second requirement and then refactor the Java implementation to make the test pass Requirement 2: When an empty string is passed as an argument to add() it should return 0 [Java Tests] [Java Implementation] Explanation: In the refactored code we have changed the return type of the add method from void to int and added the return statement to fulfill the requirement; if an empty string is passed then the method should return 0. To fail the last test you can return any other integer instead of 0. Requirement 2 Test Failed [Refactored Code] Requirement 3: Method will return the sum of numbers [Java Tests] [Java Implementation] References: The example of the string calculator has been taken from the Roy Osherove Katas. Don’t click the link until you’re finished with other parts of this blog series. This exercise is best done when not all requirements are known in advance.

TDD Test-Driven-Development

How TDD (Test-Driven-Development) works (Part 1)

Test-driven development (TDD) is a software development process in which a developer writes the code repeatedly in a very short development cycle: first, the developer writes an (initially failing) automated unit test that defines how a new feature should work or what to expect when extending existing functionality, then writes the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. The following is the flow chart of the TDD cycle There are a lot of articles produced on TDD and Wikipedia is generally a decent beginning. This blog post covers real tests and the development of a simple string calculator. We will learn this test-first development approach by implementing the requirements one by one without knowing them in advance. In the following section, you will find the test script with respect to each requirement and afterward the actually produced code. Read, only one requirement at a time, write the tests and the implementation yourself and compare it with the results from this blog. Keep in mind that there are multiple different approaches to writing tests and implementation. This example is only one out of many possible solutions. Let’s begin our journey! List of Requirements Create a simple String calculator with a method int Add(string numbers) The method can take 0, 1, or 2 numbers, and will return their sum (for an empty string it will return 0) for example <“ “> or <“1”> or <“1,2”> Allow the Add method to handle an unknown amount of numbers Allow the Add method to handle newlines between numbers (instead of commas). The following input is ok: “1\n2,3” (will equal 6) Support different delimiters To change a delimiter, the beginning of the string will contain a separate line that looks like this: “//[delimiter]\n[numbers…]” for example “//;\n1;2” should…

Continue Reading

usability testing

Is automating usability testing in CI/CD pipeline possible?

On the off chance that your organization isn’t trying its product constantly, you’re in a maze. As the requests of the market increasingly rise to have more programming at quicker paces of delivery, it’s impossible that an organization can depend on manual testing for a larger part of its quality affirmation exercises and stay cutthroat. Automation is crucial for the CI/CD cycle, particularly usability testing (ease of use testing). Serious organizations mechanize their testing interaction. That is good to know. The thing which is not good is that normally the extent of automation is restricted to client conduct testing that is not difficult to imitate, for instance, last & performance, and behavioral testing. The more muddled tests based on human elements are commonly passed on to efficiency-challenged manual testing. The outcome: an organization can have lightning-quick tests executing in certain pieces of the delivery interaction just to be eased back to an agonizingly slow clip when human elements testing should be obliged. There are ways by which human elements testing can be robotized inside the CI/CD interaction. Try to comprehend where human interaction in the testing system is essential, building automated processes obliging those limits. The Four Aspects of Software Testing To comprehend where human elements testing begins/stops, it’s valuable to have an applied model by which to fragment software testing by and large. One model isolates application testing into four angles: functional, last and performance, security, and usability testing. The following table explains. Type of Testing Brief Explanation Example Behavioral/Functional Examines that the software behaves as expected relative to operational logic/algorithmic consistency.   Component & Unit tests; integration & UI testing   Last/Performance Controls a software system’s responsiveness, accuracy, integrity, and stability under particular capabilities, and operating environments.   Scalability, robustness, CPU and memory utilization testing   Penetration/Security Examining…

Continue Reading