vhandit

User Story is the place PO gives his ideas about features so that developers are able to know what requirements are. Acceptance tests are these show the most valuable things of the features represented by some specific cases. Usually PO defines them, but not always. Therefore, refining existing acceptance tests – even defining new ones that cover all features of the User Story must be a worth task. Acceptance test with Given When Then pattern If we understand what we are going to do, we can complete it by 50% I have worked with some members those just start implementing the features one by one and from top to down of the User Story description. Be honest, I am the one used to be. What a risky approach! Because it might meet a case that is very easy to miss requirements or needs to re-work after finding any misunderstood things. I have also worked with some members those accept spending a long time to clarify the User Story. Reading carefully of whole User Story by defining...

In the beginning days, I have practiced TDD (Test Driven Development) using JUnit, I approached that I should test methods belong to a class. For example: I have a class with some methods: public class A{ public void method1(){ } public void method2(){ } } And then, I wrote some test methods to check the corresponding ones, for example: public class ATest{ @Test public void testMethod1(){ .... assertTrue(...); ..... assertEquals(...); } @Test public void testMethod2(){ } } After that, I know that a test method (ex: testMethod1) should just only test one thing, so I decided to write more methods for each case. It looks like the following: @Test public void testMethod1_When_Case1(){ .... assertTrue(...); } @Test public void testMethod1_When_Case2(){ .... assertEquals(...); } However, it was not a really good approach because it seems that I just focused on test the functionality of the method of the class. With the TDD approach, I knew that I s...