![]() I'm sure that using unit testing saved me a few days (or weeks) of coding and is more or less guaranteeing the correctness of my method. With testing I could start with a simple method and extend it step by step with the assurance that the simpler scenarios would still work. Without unit testing I did not know how to start coding, the problem seemed overwhelming. This is how I managed to create my very complex payment method. Then I worked my way down to the more complex scenarios.ģ) Run that single test to see if it would passĤ) If it didn't I'd debug and modify the code until it would pass.ĥ) While modifying code I kept on running all tests While testing for correctness with a payment discount, I also tested the simple payment. Then I started to write the second test, this time working with a payment discount.Īfter I wrote the test I modified the payment method to support discounts. I ran the first test, fixed a small bug until my test would pass. I did not yet think about the other, more complex, scenarios. In the coding I only bothered with code to make the first test pass. I check for the number of payments, the payment amounts, the discount amount and the balance of the invoice after the transaction.Īfter the test ran I would go to the database and double check if what I expected was there.Īfter I wrote the test, I started coding the payment method (part of the BankHeader class). In my asserts I put what should be the correct numbers ending up in the Bank transaction and in the linked Invoice. Then I created the first TestMethod, testing a very simple payment of a single invoice without any payment discounts.Īll the action in the system would happen when a bankpayment would be saved to the database.Īs you can see I created an invoice, created a payment (a bank transaction) and saved the transaction to disk. Normally a user would enter that information through a user interface. Then I wrote a second method to create the actual payment. I started to write (inside the test code) a method to create a list of invoices, both for sales and purchases. This is where unit testing came to the rescue. So I had a very complex problem to solve with many possibilities that one scenario would work perfectly but would be wrong on an other type of invocie/payment combination. You can expect your customer to pay you $200 to settle the balance.Īnd what if you sold for $500 but the customer pays you only $250? So you sold him for $300 but you bought for $100. Maybe you have sent sales invoices to a customer but you have also purchased from that customer. ![]() I just didn't know how to start coding it, as there were so many different payment options.Īn invoice could be $100 but the customer only transferred $99. The part I'm talking about is a method to pay sales and/or purchase invoices already entered into the accounting system. This part was very complex as it involved a lot of different scenarios. Then we had to rewrite an important piece of code in our accounting program. ![]() This got me into unit testing and it made me very happyįor a long time I knew it would be good to start doing it but I had no idea how to start and more importantly what to test. I hope this means we can move on from "getters and setters" :) You are trying to improve your craft, feel good about Don’t go running off and trying to get your head round Only think about writing tests when you are writing new May I also recommend taking a look at my blog post (which was partly inspired by my question), I have got some good feedback on that. Many great responses to this are also on my question: " Beginning TDD - Challenges? Solutions? Recommendations?" ![]()
0 Comments
Leave a Reply. |