Test Driven Development - Phương pháp phát triển phần mềm theo hướng viết test trước.
Áp dụng TDD sẽ đem lại cho bạn thiết kế phần mềm trong sáng hơn và quản lý được chất lượng từng dòng code của mình viết ra.
Bài trình bày của bạn Lê Anh tại Meetup của Ha Noi .NET Group.
Chi tiết vui lòng xem tại: http://tungnt.net
4 Nisan 2015 tarihinde Kadir Has Üniversitesi'nde yapılan 9. Yazılım Teknolojileri Seminer etkinliğinde Eralp Erat'ın yaptığı TDD (Test Driven Design) sunumu
San Francisco Software Craftsmanship Meetup
Test Driven Developers Bay Area Meetup
TDD Flow: The Mantra in Action” is a talk + hands-on about the mantra of TDD and its core patterns. Here are some questions for this talk: What is TDD? How to write a good test that fails? How to write code enough to make the test pass? How to remove duplication? How to refactor code? How to create clean code? Is TDD about testing or design? How small should a test be? Should I only write unit tests? Should I estimate TDD? How to use TDD with other agile methods like Scrum, Kanban or BDD? And finally, how to flow in TDD?
Test Driven Development - Phương pháp phát triển phần mềm theo hướng viết test trước.
Áp dụng TDD sẽ đem lại cho bạn thiết kế phần mềm trong sáng hơn và quản lý được chất lượng từng dòng code của mình viết ra.
Bài trình bày của bạn Lê Anh tại Meetup của Ha Noi .NET Group.
Chi tiết vui lòng xem tại: http://tungnt.net
4 Nisan 2015 tarihinde Kadir Has Üniversitesi'nde yapılan 9. Yazılım Teknolojileri Seminer etkinliğinde Eralp Erat'ın yaptığı TDD (Test Driven Design) sunumu
San Francisco Software Craftsmanship Meetup
Test Driven Developers Bay Area Meetup
TDD Flow: The Mantra in Action” is a talk + hands-on about the mantra of TDD and its core patterns. Here are some questions for this talk: What is TDD? How to write a good test that fails? How to write code enough to make the test pass? How to remove duplication? How to refactor code? How to create clean code? Is TDD about testing or design? How small should a test be? Should I only write unit tests? Should I estimate TDD? How to use TDD with other agile methods like Scrum, Kanban or BDD? And finally, how to flow in TDD?
This workshop is designed specially for Queen Mary University of London alumni, in order to teach them TDD.
You will learn: What is TDD, Why and How.
If you want to learn more: https://github.com/MyPitit/TDD
Test-Driven Development is about approaching software development from a test perspective and knowing how to use the tools (e.g. JUnit, Mockito) to effectively write tests.
Source code examples @...
https://github.com/codeprimate-software/test-driven-development
Lightening Talk I gave at Inaka in May 2014.
This is sort of the continuation of my previous iOS TDD talk.
Since TDD and DI go quite hand in hand and they are both extend concepts to learn in one shot, I had to prepare a completely separated talk for spreading to my fellows the DI knowledge I had acquired.
TDD vs. ATDD - What, Why, Which, When & WhereDaniel Davis
This is a slide deck for a discussion about Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) and starting to explore the differences between them. Get some insight into why we use them and the advantages and disadvantages of both, as well as, get a better understanding of which should be used where and when. By the end of the session you should be well along the path to TDD vs. ATDD enlightenment.
A quick paced introduction to "Test Driven Development" (TDD) in an agile environment. The TDD philosophy states that you should develop your tests and then write code to make your tests pass and satisfy user requirements.
Slides from the session "TDD - That Was Easy!" presented by Fadi Stephan from Kaizenko at AgileDC2019 on September 23, 2019 in Washington DC. A blog post accompanying this talk will be published soon on kaizenko.com
Abstract:
Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?
You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will look at the benefits of TDD, discuss the resistance to TDD and uncover some common difficulties along with misconceptions. We will address these misunderstandings and explore different approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD and apply it with ease
Test driven development (TDD), a software development method, helps build high quality applications faster. Life-cycle, usefulness, limitations and similar techniques of TDD have been presented in this slide deck.
This workshop is designed specially for Queen Mary University of London alumni, in order to teach them TDD.
You will learn: What is TDD, Why and How.
If you want to learn more: https://github.com/MyPitit/TDD
Test-Driven Development is about approaching software development from a test perspective and knowing how to use the tools (e.g. JUnit, Mockito) to effectively write tests.
Source code examples @...
https://github.com/codeprimate-software/test-driven-development
Lightening Talk I gave at Inaka in May 2014.
This is sort of the continuation of my previous iOS TDD talk.
Since TDD and DI go quite hand in hand and they are both extend concepts to learn in one shot, I had to prepare a completely separated talk for spreading to my fellows the DI knowledge I had acquired.
TDD vs. ATDD - What, Why, Which, When & WhereDaniel Davis
This is a slide deck for a discussion about Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) and starting to explore the differences between them. Get some insight into why we use them and the advantages and disadvantages of both, as well as, get a better understanding of which should be used where and when. By the end of the session you should be well along the path to TDD vs. ATDD enlightenment.
A quick paced introduction to "Test Driven Development" (TDD) in an agile environment. The TDD philosophy states that you should develop your tests and then write code to make your tests pass and satisfy user requirements.
Slides from the session "TDD - That Was Easy!" presented by Fadi Stephan from Kaizenko at AgileDC2019 on September 23, 2019 in Washington DC. A blog post accompanying this talk will be published soon on kaizenko.com
Abstract:
Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development?
You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc… However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will look at the benefits of TDD, discuss the resistance to TDD and uncover some common difficulties along with misconceptions. We will address these misunderstandings and explore different approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD and apply it with ease
Test driven development (TDD), a software development method, helps build high quality applications faster. Life-cycle, usefulness, limitations and similar techniques of TDD have been presented in this slide deck.
You’re finally doing TDD, but your past mistakes are catching up with you. No matter what you do, you can’t get rid of the gaping black holes caused by your legacy code.
In this presentation, we learn about the causes of legacy code and the reasons it is so difficult to work with. Then we discuss various techniques to test untestable code, revive and simplify incomprehensible code, redesign stable yet untested code, and repair that rift we created in the time-space continuum.
Test Driven Development (TDD) & Continuous Integration (CI)Fatkul Amri
Sebuah pembahasan menarik tentang Agile Software Development dengan Test Driven Development (TDD) & Continuous Integration (CI). Materi ini disusun oleh Mas Disyam
TDD is now mainstream but a lot people don't know or don't remember what is its purpose. TDD is about software design not testing or catching bug. TDD helps developers to shape and create software with "good" design, what is a "good" design is something that we will discuss in the topic.
This talk was geared around the concept of showing developers what goes into getting enterprise products out the door. Unit testing, release process, continuous integration, security, social engineering, bug bashes.
TDD is now mainstream but a lot people don't know or don't remember what is its purpose. TDD is about software design not testing or catching bug. TDD helps developers to shape and create software with "good" design, what is a "good" design is something that we will discuss in the topic.
Essential Eclipse Plug-ins and Tools for Flash Builder DevelopersElad Elrom
Here are the presentation slides for the presentation I gave at MAX 2011 Los Angeles, CA. In this presentation I have covered “Essential Eclipse Plug-ins and Tools for Flash Builder Developers”
Exploring essential plug-ins and tools that every developer should add to their Adobe Flash Builder installation. In addition to covering configuration of the plug-ins, Exploring how to use them as part of a workflow for rapid development of Flex and ActionScript applications.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
2. @EladElrom Associate Dev Director @ Sigma Group Senior Flash Engineer & Lead Technical Writer FlashAndTheCity Organizer Adobe Community Professional
3. TOC USING FLEXUNIT 4 WITH TEST DRIVEN DEVELOPMENT Test Driven Development quick overview Defining Application’s Objective User Stories GETTING STARTED Creating the application Creating the class to be tested Creating your first Test Suite Add your first test case class IMPLEMENTING YOUR USER STORIES Retrieve Tweets User Story Retrieve tweets every few seconds User Story
4. Show & tell How many of you have used TDD? How have of you have tried to use TDD and gave up? How many always wanted wanted to use TDD but never did?
6. Asshole Driven Development (ADD) Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway. Scott Berkun
7. Cover Your Ass Engineering (CYAE) The driving force behind most individual efforts is to make sure than when the shit hits the fan, they are not to blame. Scott Berkun
8. Duct-tape Driven Design (DDD) Get it out the door as quickly as possible, cut-n-paste from anything that you find that works on Google, if it works it’s ready
12. Disadvantages of Waterfall Process Creating tasks based on developer’s opinion rather than project’s needs. Spending time on technical design documents such as UML diagrams. May create code that is not used in the app and increase development time. One programmer code may break another programmer code. Many time methods do more than one task and code is hard to maintain. Changing requirements may require re-engineering parts of the app.
14. What’s TDD? The concept is pretty simple. You write your tests before you write your code. It’s that simple and worth repeating: write tests before code! Test Driven Development is a software development technique in which programmers are writing a failed test that will define the functionality before writing the actual code.
16. Developers are lazy! Software developers our job is to be lazy.Lazy = Efficient.. Really? We automate repetitive tasks. Yet we most of our time testing and debugging our code manually (80% as some studies suggest). Why would you choose to do this repetitive and annoying task when you automate all of the others?
17. Automate testing Let humans do the work they do best while letting computers do the work they do best and ending up with code that is more stable and more maintainable!
18. Furthermore The concept of TDD is based on Extreme Programming (XP) development paradigm, which talks about teams that work on the development of dynamic projects with changing requirements and a development cycle that includes TDD for writing the test before the code itself. TDD is not the complete development cycle; it is only part of the Extreme Programming (XP) development paradigm. Preparing the tests before writing the code helps a development team to demonstrate their work in small steps, rather than making the customer or other stakeholders wait for the complete result. Moving in small increments also makes it easier to accommodate changing requirements and helps ensure that your code does what it needs to do, and nothing more. It is important to mention that the focus of the TDD technique is to produce code and not to create a testing platform. The ability to test is an added benefit. TDD is based on the idea that anything you build should be tested and if you are unable to test it, you should think twice about whether you really want to build it.
19. “The single most important effect of practicing TDD is that it forces you as the developer to be the first consumer of your own API.” Brian Button
20. TDD Rules You are not allowed to write any production code unless it is to make a failing unit test pass. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. Via butunclebob.com
21. What most programmers think about TDD when they are first introduced to the technique?
22. Programmers respond: "This is stupid!" "It's going to slow me down” “It's a waste of time and effort” “It will keep me from thinking” “It will keep me from designing” “It will just break my flow” Via butunclebob.com
23. Defining Application’s Objective Understanding the application objectives is as important as coding your application. Here’s a Lessons we can learn from a Master Carpenter: MeasureTwice, Cut Once!
24. Defining Application’s Objective You need to understand what you are developing before you get started. In our case, we are building an application that will do the following: Allow attendees to communicate with each other through twitter API. The class will keep a list of tweets with #FlashAndTheCityhashtag The class will check for updates of tweets often
25. User Stories A good approach to take to ensure the tasks are defined well is to follow Agile software development mythology. The Agile mythologies talks about creating one or more informal sentences in an everyday or business language, this type of approach is known as a User Story. The User Story should be limited in characters and should fit a small paper note card. The user stories are usually written by the client in order to give direction to build the software. Think of this list as your todo list. In our case here are the User Stories: Retrieve tweets with #FlashAndTheCityHashTag from Twitter API. Have a service call to twitter and retrieve tweets every few seconds. Login into user's twitter account and retrieve personal information. Store user's information so user wouldn’t have to login again every time. Post a tweet on twitter from a user Add #FlashAndTheCityHashtag to a tweet so user wont have to type it every time and the application will be able to retrieve all tweets related to the conference. Keep a list of tweets with the ability to add a tweet & remove a tweet.
26. Creating the application With the knowledge of what we need to develop we are ready to get started. The first step is to create the application open Eclipse or Flash Builder 4 Beta and create a new project name Companion (see instructions below). Select File > New > Flex Project to create the project. For the Project Name, type Companion, ensure you set the project as Desktop application type. Click Finish.
27. Creating your first Test Suite A test suite is a composite of tests. It runs a collection of test cases. During development you can create a collection of tests packaged into test suite and once you are done, you can run the test suite to ensure your code is still working correctly after changes have been made. To create a test suite, choose File > New > Test Suite class.
28. Continue After you select New Test Suite Class a wizard window opens up. Fill in the following information: In the New Test Suite Class dialog box, name the class CompanionTestSuite. Select New FlexUnit 4 Test. Click Finish.
29. Look at your Test Suite Flash Builder 4 added the following class under the flexUnitTests folder: packageflexUnitTests { [Suite] [RunWith("org.flexunit.runners.Suite")] publicclassCompanionTestSuite { } } The Suite metadata tag indicates that the class is a suite. The RunWith tag instructs the test runner to execute the tests that follow it using a specific class. FlexUnit 4 is a collection of runners that will run a complete set of tests. You can define each runner to implement a specific interface. You can, for example, specify a different class to run the tests instead of the default runner built into FlexUnit 4.
30. FlexUnit 4 Metadata The FlexUnit 4 framework is based on metadata tags. So far you've seen [Suite], [Test], and [RunWith]. Here are some other common metadata tags: [Ignore] - Causes the method to be ignored. You can use this tag instead of commenting out a method. [Before] - Replaces the setup() method in FlexUnit 1 and supports multiple methods. [After] - Replaces the teardown() method in FlexUnit 1 and supports multiple methods. [BeforeClass] - Allows you to run methods before a test class. [AfterClass] - Allows you to run methods after a test class.
31. Add your first test case class Next, you need to create a test case. A test case comprises the conditions you want to assert to verify a business requirement or a User Story. Each test case in FlexUnit 4 must be connected to a class. Create the Test Case class: Choose File > New > Test Case Class. Select New FlexUnit 4 Test. Type flexUnitTests as the package. Type TwitterHelperTesteras the name.
32. Add a Reference Important: Ensure that there is a reference in CompanionTestSuite.as to TwitterHelperTester: packageflexUnitTests { [Suite] [RunWith("org.flexunit.runners.Suite")] publicclassCompanionTestSuite { publicvartwitterHelperTester:TwitterHelperTester; } }
33. Implementing your User Stories Retrieve Tweets User Story We can start with the first User Story, Retrieve tweets with #FlashAndTheCityHashTagfrom Twitter API.
34. Understand your goal In our case we are testing that the service is working correctly. We are using a public API that is maintained by Twitter and creating a Mashup application. Using a well maintain API helps us creating our application quickly, however it also store a disadvantage that in any time Twitter may change their API and our application will stop working. We are testing that the fail and success events are dispatching correctly and ensuring that the API is working, see the code below:
38. Working on the compilation errors Save the file and now you see a compile time error: Call to a possibly undefined method retrieveTweetsBasedOnHashTag through a reference with static type utils:TwitterHelper. This is actually a good. The compiler is telling you what you need to do next. We can now create the method in TwitterHelper in order to get rid of the compiler error.
39. Create TwitterHelper – write min code packageutils { importflash.events.EventDispatcher; importflash.events.IEventDispatcher; publicclassTwitterHelperextendsEventDispatcher { publicfunctionTwitterHelper(target:IEventDispatcher=null) { super(target); } /** * Method to send a request to retrieve all the tweet with a HashTag * @paramhashTag defined hashtag to search * */ publicfunctionretrieveTweetsBasedOnHashTag(hashTag:String):void { // implement } } }
40. Run FlexUnit Tests Compile the project and we don’t have any compile time errors and you can run the tests. Select the Run icon carrot and in the drop menu select FlexUnit Tests.
41. Review the Results Flash Builder opens a new window where the tests are run and shows the results of your test, see below: 1 total test was run 0 were successful 1 was a failure 0 were errors 0 were ignored
43. Change the Test from Fail to Pass In order to pass the test you now need to write the actual code. At this point we wrote the test and once we write the code the test will succeed. I have implemented the code to call Twitter and retrieve results that includes #FlashAndTheCityhashtag Write the code on TwitterHelper; retrieveTweetsBasedOnHashTag & onResults methods
44. Write code packageutils { importcom.adobe.serialization.json.JSON; importflash.events.EventDispatcher; importmx.rpc.events.FaultEvent; importmx.rpc.events.ResultEvent; importmx.rpc.http.HTTPService; publicclassTwitterHelperextendsEventDispatcher { /** * Holds the service class */ privatevarservice:HTTPService; //-------------------------------------------------------------------------- // // Default Constructor // //-------------------------------------------------------------------------- publicfunctionTwitterHelper() { // implement } /** * Method to send a request to retrieve all the tweet with a HashTag * @paramhashTag defined hashtag to search * @url the twitter API url * */ publicfunctionretrieveTweetsBasedOnHashTag(hashTag:String, url:String):void { service = newHTTPService(); service.url = url; service.resultFormat = "text"; service.addEventListener(ResultEvent.RESULT, onResults); varobject:Object = new Object(); object.q = hashTag; service.send( object );
45. Write code #2 } //-------------------------------------------------------------------------- // // Event handlers // //-------------------------------------------------------------------------- /** * Method to handle the result of a request to retrieve all the list * @param event * */ privatefunctiononResults(event:ResultEvent):void { service.removeEventListener(ResultEvent.RESULT, onResults); service.removeEventListener(FaultEvent.FAULT, onFault); varrawData:String = String( event.result ); varobject:Object = JSON.decode( rawData ); varresults:Array = object.resultsas Array; varcollection:Vector.<TweetVO> = new Vector.<TweetVO>; results.forEach( functioncallback(item:*, index:int, array:Array):void { vartweet:TweetVO = newTweetVO( item.from_user, item.from_user_id, item.geo, item.id, item.profile_image_url, item.source, item.text, item.to_user, item.to_user_id ); collection.push( tweet ); }); // dispatch an event that holds the results this.dispatchEvent( newTwitterHelperSuccessEvent( collection ) ); } } }
46. Run your test again Run the test again and observe the results. A test that does not fail succeeds Click the Run Completed Button Observe the Green Bar that indicates success
47. Refactor At this point, we can do a small refactoring to the test case and include the static method from the custom event instead of having the string attached, which will ensure our tests still pass in case we refactor the event type string, see code below: classToTestRef = newTwitterHelper(); varEVENT_TYPE:String= TwitterHelperSuccessEvent.RETRIEVE_TWEETS;
48. Refactor tests - tests have duplication that can become painful to maintain In our case, we need to instantiating TwitterHelper in each test. Granted, there are just two, but this will grow We can solve this problem by using additional metadata provided by FlexUnit 4 called [Before] and [After] [Before] can be applied to any method that you wish called before each test. [After] will be called after each test For good measure, let’s add a method name tearMeDown() and mark it with the [After] metadata. The [After] method gives you a place to clean up from your test case. In this case just set classToTestRef equal to null so the instance is available for garbage collection In more complicated tests it is often crucial to remove listeners, etc. in this way. In our case TwitterHelper is already removing the listeners so we don’t need to do that, but many other times you will.
49. Refactorthe actual code We focus on passing the test and didn’t care that much about the code, however you may find out that the code is too complex and can be simplify by implementing a design pattern, or just adding some small modification. For instance, I can add metadata so when you instantiate the class and add event listeners in MXML component you will get the event type available automatically. Add the code below to the TwitterHelperclass.
50. My personal notes about TDD Don’t use TDD for Micro-architecture User Gestures. Usually avoid using TDD for testing GUI. Use TDD for building APIs, frameworks, utilities and helpers. Use TDD for testing services. Use TDD for code that will be used on more than one application.
51. Where to go from here? Adobe Developer connectionhttp://www.adobe.com/devnet/flex/articles/flashbuilder4_tdd.html Flash&Flex Magazine:http://elromdesign.com/blog/2010/01/19/flexunit-4-with-test-driven-development-article-on-ffdmag/