- 1. Test Driven Development (TDD)
San Jose 360|Flex
Associate Dev Director @ Sigma Group
Senior Flash Engineer & Lead
Adobe Community Professional
USING FLEXUNIT 4 WITH TEST DRIVEN DEVELOPMENT
Test Driven Development quick overview
Defining Applications Objective
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?
5. In Software Engineer, Whats your development techniques options?
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.
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.
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 its ready
9. Now Seriously...
10. 11. WaterfallSoftware Development Process
12. Disadvantages of Waterfall Process
Creating tasks based on developers opinion rather than projects 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.
13. Whats the alternative?
14. Whats TDD?
The concept is pretty simple.You write your tests before you write your code.Its 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.
15. Process overview
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!
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.
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.
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
23. Defining Applications Objective
Understanding the application objectives is as
important as coding your application. Heres a
Lessons we can learn from a Master Carpenter: MeasureTwice, Cut Once!
24. Defining Applications 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 wouldnt 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.
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.
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.
29. Look at your Test Suite
Flash Builder 4 added the following class under the flexUnitTests folder:
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: