A Story about User Stories and Test-Driven Development
Gertrud Bj?rnvig, Gertrud & Co., Esperg?rde, Denmark
James O. Coplien, Nordija A/S, Kongens Lyngby, Denmark
Neil Harrison, Utah Valley University, Orem, Utah, USA
Welcome to TDD
Test-Driven Development, or TDD, is a term used for a popular collection of
development techniques in wide use in the Agile community. While testing is
part of its name, and though it includes tests, and though it fits in that part of the life cycle usually ascribed to unit testing activity, TDD pundits universally insist that it is not a testing technique, but rather a technique that helps one focus one’s design thinking. The idea is that you write your tests first, and your code second.
In this article, we explore some subtle pitfalls of TDD that have come out of our experience, our consultancy on real projects (all of the conjectured problems are things we have actually seen in practice), and a bit of that rare commodity called common sense.
A Conjectural and Metaphorical History of TDD
We want to start this story with a conjecture. It is not intended to represent truth but, in a popular Agile tradition, is a foundation for metaphor and allegory to
help make some of the TDD problems more memorable. If elements of the story happen to be true, so much the better.
Once upon a time, software development was doing more or less O.K. when it
employed Use Cases to help bridge the connection between developers and end users. Healthy organizations developed Use Cases for their intended
audiences—including the coders and testers—all the while keeping them
readable by the client. Use Cases were intended to avoid over-constraining the
solution: they were written in terms of pre- and post-conditions, rather than
attempting to convey the intent in a code-centric IF-THEN-ELSE style. Alistair
Cockburn created an informal instrument to vividly present a single example of a Use Case enactment called User Stories, which had a true element of story to
them. They were never intended to survive into the project.1
However, some organizations used Use Cases in the worst possible way,
specifying details of program task sequencing instead of sticking to
1 Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2001, page 17.
requirements. For example, there might be a business rule stating that one cannot go into a normal Danish train ticket office and place an order for train travel to Sweden, and another rule stating that such tickets can still be printed at main Danish ticket offices. The organization would create Use Cases for purchasing a Danish ticket and printing it at a Danish ticket kiosk, as well as exotic extensions whereby one calls the Swedish train company and books a ticket by phone and has it printed at a main Danish ticket office. The developers would turn this into a nested if-then-else hell, rather than writing the normal sequence, delineating special cases with extensions and business rules.
On the other hand, the Extreme Programming (XP) people, wanting to take things to the opposite extreme, turned the knob up to 10 on simplicity. Use Cases gave way to Alistair’s User Stories—about 5 on the knob—which were further pared down to feature lists—all the way up to 10. Wanting to capture the market interest of those who formerly had employed Use Cases, the XP people took Alistair’s name for his Agile articulation of a user interaction with the system. The XP feature lists came to be named User Stories and Alistair went in search of another name for his concept. An XP User Story was nothing more than “a mnemonic token of an ongoing conversation about a requirement.”2 Meanwhile, Alistair’s concept—renamed to Usage Narrative—provided a good starting point for exploring the business space, a good stepping stone to more detailed Use Cases with enough information to support actual development. This concept would thrive in successful organizations as an application of the pattern Narrative and Generic.3
At about the same time, the Smalltalk community found that it was weak on testing. Part of this problem owed to the fact that most Smalltalk projects were too small to justify hiring a tester, so the only staff left to do testing were developers—who usually lacked professional testing skills. This gave birth to a testing methodology using a testing framework.4 As the XP world moved away from Smalltalk and towards Java, the approach spawned a tool called JUnit. However, as time went on, the community found that unit testing didn’t find many bugs—many still leaked through to the customer. System testing never was a big part of the culture, and in general it became difficult to sell testing to the XP constituency—testing was usually left to second-class citizens or was outsourced and, as such, was never a revenue-generating business. It didn’t help that testing wasn’t “fun,” and that “fun” is a core value of XP. The TDD
2 Agile Principles, Patterns and Practices in C#, Robert C. Martin and Micah Martin, Prentice Hall, 2007, page 14.
3Gertrud Bj?rnvig, Proceedings of EuroPLoP ’03, “Patterns for the Role of Use Cases,” page 886.
4See the original paper by Kent Beck at https://www.doczj.com/doc/883644045.html,/testfram.htm, as published in the Smalltalk Report, October 1994.
advocates motivate its value by telling us that TDD is fun—not so much for its value, but for novelty for its own sake.5 The testing framework and JUnit weren’t garnering consulting gigs any more.
Further turning the knob up to 10, the XP people chose to simplify the complexity of up-front design. Ron Jeffries tells us:
Get a few people together and spend a few minutes sketching out the
design. Ten minutes is ideal—half an hour should be the most time you
spend to do this. After that, the best thing to do is to let the code
participate in the design session—move to the machine and start typing in code.6
Architecture was replaced in concept by the smaller and more abstract notion of metaphor, and even metaphor was limited to a bit of up-front work and the occasional reference during development as needed.
The approach left much to be desired. Programmers found that they needed a written record of some of the finer details of scenarios—much finer than what a User Story conveyed. They needed these in part just to help them understand requirements, but also needed them to write their tests. At the same time, while XP criticized heavyweight up-front design, it offered no real alternative except to “let the code do the talking.”
One brilliant idea would address all of these problems: to re-cast the JUnit test scripting as a design activity rather than as a testing activity. This made the central concepts of XP more appealing to programmers than any testing regimen would, because design is fun. Development would necessarily start with JUnit: you had to write a test before writing any code. At the same time it appeased the collective conscience of the community by having a testing technique (now to publicly be called a design technique) in its vocabulary, addressing the weakness uncovered in 1994. XP could now point to TDD as its design methodology—something close to the programmer and far from the heavyweight architects as well as the second-class-citizen testers. It made sure that TDD would be portrayed that way through repeated insistence that TDD is not a testing method, but a design method. And in fact, it was touted even as an analysis method whereby we “put the analysis efforts into the tests.”7 Yet it was still offered as the safety net that allows programmers to move boldly forward by ensuring they don’t step outside the boundaries of stipulated behavior—which means to employ the scripts as tests.
5Jimmy Nilsson, “Why is TDD so Boring?” www.jnsk.se/weblog/posts/tddisfun.htm, weblog of 22 March 2007, accessed 10 July 2007.
6Ron Jeffries et al., XP Installed, Addison-Wesley, 2000, page 70.
7Steve Freeman, “Test Driven Development: How do we know when we’re done?” QCon, QE-II Conference Center, London, 15 March 2007.
A Journey with some Metaphorical Developers
The XP approach as it converged over the years appears to balance all of the
forces: the need to engage the development community as well as the user
community, the need to capture low-level scenario information, a sustained
market for JUnit and the need to avoid heavyweight techniques such as up-front architecture. But in solving what were supposedly serious problems, is it
possible that these changes actually made trouble? You’ve heard the tutorials;
you’ve read the books. The three of us, in our work together with many clients,
have seen where the rubber meets the road, and have had the opportunity to
follow TDD projects over the course of several months (or, sometimes, years) to assess the long-term damage. Let’s follow our metaphorical project around for a while to elucidate possible TDD pitfalls.
So the XP programmer came to work one morning, found a list of User Stories,
and paired up with a colleague who had been working in the same area, and the two decided to code a certain User Story that day. They discussed between them how the feature should work and discovered they had to write two test cases to cover the User Story. They wrote the tests and, true to the TDD methodology,
executed them before writing any code to ensure that they would fail. They did.
It was simple — it took about ten minutes, well within a single Ron Jeffries
design sprint.
The same pair then coded up the class. This, as it turns out, took a bit more
work—about an hour of iterating the code to pass the tests. Along the way the
pair created two more tests. Predictably, when they were finished, all four tests
passed.
Here we find our first risk:
1I f the same people write both the tests and the code from the
same base understanding or formalism, the chances of creating a
self-fulfilling prophecy are high.
Here’s the problem: Most software bugs reflect assumptions of the coder rather
than an incorrect conveyance of those assumptions in code. A single programmer has a single set of assumptions, and any traps within such assumptions will not be caught if the same programmer writes the code and the test. This can happen even in simple cases, such as creating a linked list. Our programmers didn’t
know that their train reservation library would be used in a multi-threaded
system, with the potential for one thread to be traversing a list of scheduling
options while another application might be updating routing information in real
time. Eventually, this error would cause a member of the National Assembly to miss getting a train into the city for an important vote on a conflict with Sweden which would turn the political tide and ultimately lead to World War III.
Even two programmers who are pairing can mislead each other into assumptions that would be broken by at least one of a separated pair. To put it differently, pair design and pair programming lead to pair assumptions—a variation on groupthink. To remedy this pitfall, use the following techniques:
9Develop the test from a different set of formalisms than are used for the design. For example, derive the design from a good Use Case
description, while deriving the test from business rules or invariants.
9Have a different person develop the tests than the one who develops the code.
You can use either or both of these techniques together.
The team develops a bit further and is considering another set of User Stories. The pair can see that these User Stories have detailed cases that interfere with assumptions made in a previous test case. In particular, they have found that a previous test case presumed that a given reservation could be found in the database using a ticket kiosk ID or main office ID as a primary key. The primary key captures the site making the original reservation of any ticket issued in Denmark. However, the new User Story offers that the end user can reserve a ticket to Sweden by calling the Swedish train company on the phone, and then issue the ticket at a main Danish train company location—even though it is impossible to directly make a booking to Sweden at a main Danish train office. This leads to our second risk:
1U ser Stories (promises for a future discussion between a developer and
a customer), processed and elaborated in isolation during coding, fail to
capture the interesting extensions that come about from feature
combinations or exceptional conditions. There is nothing to encourage
the coder to think about these at TDD time: indeed, because many of
these extensions involve multiple objects, such considerations are likely never to arise at the class level.
To fix this, we again go back to the future:
9Develop and iterate Use Cases up front, giving good coverage to all of the cases relevant to your next customer deliverable, and capturing
other pre- and post-conditions that you know. Give particular attention to Use Case extensions and exceptions so you understand boundary
cases. While the code may ultimately be the design, it is totally
inappropriate as a tool to support the social activities of design. Use
Cases, on the other hand, support a culture of dialogue with the client.
As you write the Use Cases you will discover conflicts — conflicts even at the business level. A classic example from telephony is that you develop the call waiting feature, and then the call forwarding feature. If you develop either one independently, you miss facing the decision of what to do when a client is on a call, has call forwarding enabled but also subscribes to call waiting—and someone attempts to place a call to that client. If you capture this scenario information in JUnit or Cactus, one User Story at a time, you risk major rework at some point along the way—not only of code, but of the tests as well. It is a design issue that affects the most fundamental structures of the code—structures you can’t refactor into the code if you miss them the first time around. Even worse, and perhaps more likely, is that your end user won’t discover requirements bugs until deployment—bugs that could have been caught by clarifying scenarios before a single line of code is written. You can improve the stability of both your code and of your tests by using Use Cases as a kind of “fixed point” of development.
The developers hear our suggestion and they go back and re-do the original reservation User Story—including re-writing the test (and then it fails) and updating the code (the test still fails) and going into several iterations with test and code until both fit each other (that is, the test passes) and they seem to fit the modified understanding of the functionality (which was never captured in a test before the decisions were reduced to code.) The code ends being a mess because of these missed assumptions. No problem: they’ll re-factor their way out of it. However, the refactoring browser isn’t much help because most of the re-structuring at this point is taking place across class hierarchies. Well, we still tell the boss it’s re-factoring and after a small one-week delay (on a two-week sprint), we’re in good shape. In the mean time, our competitor has shipped another release.
This leads us to the third risk:
1L ack of good architectural delineation from up-front design and Use Cases can lead to major re-structuring events as the team learns, a bit at
a time, what the system structure is supposed to look like. Re-factoring
often isn’t an option, sometimes because the changes go beyond what
good re-factoring can achieve and take us into the arbitrarily general
world of hacking and re-design.
The solution:
9Do just enough up-front lightweight architecture to support the structuring of the development organization, to map on to the physical system architecture, and to do a good job of supporting usability. One
important consideration is that the structure of the code fit the structure of the human/computer interface, so the development team should take cues from usability people when formulating the system object
structure.
The team checks out recent empirical findings by Maria Siniaalto and Pekka Abrahamsson and is relieved to find that they have done exactly the right thing.8 Our developers found the same thing that Maria and Pekka did: that the use of TDD makes key architectural indicators worse. That runs counter to common claims that TDD leads to more cohesive systems. Though local complexity metrics are a bit better with TDD than without, the dependency management metrics were clearly worse. TDD is an architectural nightmare. But, architecture in hand, our adventuresome developers are again back on track.
It’s finally time to demo the system to the customer, and the customer sits down and enters an unforeseen illegal sequence of keys. The customer turned out to be a good tester, because the program crashed. The sequence entered by the customer-as-user put the system into a state that had been unforeseen by the developers in fleshing out the user stories. It was certainly not a scenario the customer would have thought up beforehand; exhaustively enumerating error cases is, well, exhausting. The problem was in the interaction between two objects rather than in any single object.
Now we come to the fourth risk:
1T esting individual classes leads to no guarantees about the soundness of the objects of that class interacting with the objects of another,
8Siniaalto and Abrahamsson, Comparative Case Study on the Effect of Test-Driven Development on Program Design and Test Coverage, ESEM 2007.
independently tested class—or even between cooperating objects of that
single class.
This problem, too, can be resolved:
9Write tests at the level of some meaningful business concept. The test should be something traceable to customer desiderata and possible
system-user interactions, not to something inside the system.
9Tests should be written directly from customer input rather than from something created by the developer in isolation. Too many tests are
created from the programmer’s internal understanding of the program,
rather than from an understanding of business needs—which are often
emergent properties resulting from the interaction of several classes.
There is rarely a direct mapping from the systems thinking of solving
user/business problems to the structure of a simple, individual class.
Only in those systems where such mapping is straightforward do
simple techniques work. Few systems of interesting commercial value
are so simple.
The project takes our advice and in fact re-does everything so that the tests now reflect concerns of business value. The team has built a collection of individually robust objects that all pass their tests. A few of them have mocks, but the team
has been smart to build higher-level constructs on lower level ones. True to TDD, they do this one test at a time, each one driving some functionality of some
object, which in turn may depend on other objects below it.
So the team has struggled to get the first iteration to market. The industry knows that first iterations are easy: almost anything works on a greenfield project
undertaken by a single small team. But Agile talks about change, and changes
happen. Agile doesn’t talk about bugs, and bugs happen. What are the
repercussions of change and bugs on a TDD system? How about the propagation of change through the test code? How about the architecture’s ability to
encapsulate change when the structure rests on the execution paths of the first
release? Will our team succeed, or will they continue to learn their way out of
these problems? Things have only yet begun to be interesting.
Reflecting on Where We Are So Far
So far, we have introduced a small team using Test-Driven Development as their design method. Our metaphorical project struggled to deliver a product, and that
many of the struggles owed to TDD itself. These are not small bugs and are not limited to testing, or even to design. A TDD-driven approach traditionally builds on user stories instead of Use Cases, which leads to poorly specified systems and inordinate rework. It leads to very spotty coverage of the design space, ignoring the most important aspect of design: the interactions between the parts. It causes developers to become blindsided, developing code and tests guaranteed to
validate each other.
Some of these problems owe to common practice which TDD founders may
discount as misguided. However, that makes these practices no less common,
whether because the development world can’t understand the subtleties beneath TDD or because all the consultants and lecturers get it wrong. We have attended many tutorials on TDD within the past year, and our story reflects practices that they advise.9 But some of the problems telegraph a short-sightedness in TDD
itself: the need for short-term gratification—er, feedback—that too often ignores serious long-term consequences.
Our team struggled to get their software to the field. We congratulate them.
Let’s pick up the story where we left off.
Change Happens
Another customer comes along with a killer bug. The development team goes in and tries to find it, yet the system is doing exactly what it is supposed to be
doing: all the tests pass, yet the system doesn’t work right. After three days of
head-scratching the team finds that, in fact, one of the tests is wrong: just a
coding error in the Java code for the test. Woops. Once the test is fixed, it fails. It turns out that this is a fairly common case, and that the word on the street had in fact been that at many TDD companies the motto was: “We don’t fix bugs, we fix tests.”
Here come the fifth and sixth risk:
1I n a typical TDD setting, half the code mass comprises unit tests. Those tests are code. Where there is code, there are bugs.10 Programmers are
psychologically programmed to trust their tests over their code—even
though it takes only five minutes to write the test and an order of
9For example: Steve Freeman, “Test Driven Development: How do we know when we’re done?” QCon, QE-II Conference Center, London, 15 March 2007; Jimmy Nilsson, “TDD, That’s the way,” ?redev 2006, Malm?, Sweden, 15 November 2006; and, Mary Poppendieck, “Stop-the-Line Quality,” ?resund Agile, Copenhagen, 13 June, 2007.
10See, for example, Matt Stephens and Doug Rosenberg, Extreme Programming Refactored.
magnitude longer to write the code. They sometime will make arbitrary changes to the code to make the test pass, even without understanding.
(Sorry, it happens.)
1H aving a high density of testing code relative to the delivered code can actually increase the number of bugs in the delivered code!
To fix these problems:
9Test at a coarser level of granularity—perhaps at some level of integration that makes business sense. That reduces the testing code
mass relative to the delivered code mass.
9Make sure that tests and code are independently developed.
9Don’t neglect system testing.
In fact, we tell them the story of Ada compiler development in the 1980s. It was a test-driven project driven by an acceptance suite. Most suppliers used the test suite to validate their compilers. Not Nokia: they verified it against the Ada language definition. The Nokia compiler was the only Ada compiler not to exhibit the rendezvous bug that had been institutionalized in the test suite. There is currently a similar problem in the g++ test suite, in which a colleague of ours recently found more than 40 bugs.
The software world is starting to learn this. As of 2005 an Agile advocate and software notable would finally reverse his earlier position and say, “Having the system-level tests before you begin implementation simplifies design, reduces stress, and improves feedback.”11
Over time, the system evolves and the team eventually works out the bugs. The system goes to its first customer. Things go pretty well for the first two releases, though the competition has been making good inroads into the market. But the feature velocity is slowing because it’s difficult to turn around change quickly. To check in code, the unit tests have to pass. It now takes 25 minutes to run the tests. Projecting into the next release we see that the time will soon grow to an hour. In general, the ceiling is unbounded.
11See Kent Beck, Extreme Programming Explained, 2nd Edition, Pearson, 2005, page 28.
This brings us to the seventh risk:
1W riting tests at the granularity of classes and member functions will create a large code mass whose maintenance will reduce your feature
velocity, and for which the test times can grow without bound. In some companies we have seen these test suites grow to 8 hours.
The solutions?
9Test at a coarser level of granularity. Professionally developed tests can give good coverage of business functionality, and can adequately
exercise code, even from a small test mass applied at fairly high-level
interfaces.
9If a given piece of code cannot be exercised from such a high-level interface, then remove it: it has no bearing on anything visible to any
external constituencies.
As a follow-on to long check-in times the team decides to review current tests. They find that many of them are in fact now obsolete—in fact, dozens of them. Some of the test failures should be ignored, and some developers set some maven flags to ignore those test results. The good news is that the team actually removes a few of the bad tests. The bad news is that they don’t create any new tests to cover the same code. The even worse news is that some of the test failures that were flagged as innocuous in fact mask real bugs that the team would find later.
After the system goes to the third customer, customers start complaining about degrading usability. The complaints seem to fall into two categories.
The first complaint was straightforward: There was a new field on one of the forms, and that when users tab rapidly from field to field, the habits they developed for a common case now cause the cursor to fall one field short of where it should be. The team couldn’t even understand the problem when they were faced with it. First, in the spirit of Smalltalk testing, they found changes in the interface to be only annoying details: in the spirit of Agile, it is “working code” that matters. Second, they had in fact tested this interface: they clicked on individual fields with the mouse and entered the relevant data, finding that the system presented the right answer when they pressed “enter”. The business logic was further validated by tests at a lower level.
We now see the eighth risk:
1T DD can give a false sense of confidence that the system is tested.
Furthermore, it pre-ordains a certain ordering of events; doing the
combinatorics is difficult and is rarely tackled by developers.
The solution?
9Do system testing—or at least test at the level of meaningful business functionality—and usability testing. Treat TDD as if it has no
validation or verification value—which is approximately true.
9To do this, you need to tell system testers what they need to test. System testers have long used well-structured Use Cases to their benefit—Use
Cases that don’t constrain testers with overly detailed descriptions
designed to “help” the programmer. Use Cases are a stronger alternative than User Stories.
9Use systematic testing techniques to reduce redundancy among test cases, to get the greatest testing benefit for the fewest number of tests.
The second complaint is a bit more problematic. The user interface proves to be not as productive as the competition’s—all of this in spite of the fact that in the last release, a good usability person worked with development to improve the interface as best as possible. A study shows that the productivity lapse comes from a long pause in operator input when faced with non-repetitive operations, and that there is a lot of rework that owes to user errors. What is going on is that the entities known to the interface are a bad match for the entities in the unconscious (and sometimes the consciousness) of the end user.
We approach the developers and they insist that they have taken our advice from last time and that they have developed the system from tests that derive directly from user desiderata. We have a look at the architecture. We see the layered structure that came out of their bottom-up approach. The main organizing principle, true to the tests, is around procedures. The business objects didn’t factor into the design, because design—true to TDD—is driven by tests. Combine this perspective with YAGNI (“you ain’t gonna need it”, another famous Agile
rallying cry) and you have a perfect recipe for ignoring broad questions of structure: it’s all about functionality.
The GUI objects of course reflect the business objects of the underlying design, in concert with Model-View-Controller principles. These principles go to the heart of object-orientation—about directly engaging the end user with the code.12 That the classes came about from pieced-together functions, rather than from broad domain thinking, leaves the system structure (and the GUI) beyond the user’s comprehension. The competition has a sound architecture of objects that capture the user conceptual model of the business, and those objects shine through in the screens, entities, and operations of the GUI. Faced with a new situation, the competition’s users are more likely to do the right thing than our users are.
This leads us to the ninth risk:
1A design driven by tests is necessarily a design driven by procedural thinking. It encourages procedural layering, rather than creating
conceptually cohesive objects. The best that even a masterful interface
can do is to capture these objects that badly reflect the user mental
model.
To fix this:
9Do a little up-front design, as described above. The architecture of a system is visible to the user in the way it works. Kent Beck once said
that a good interface can’t hide a bad design, and Trygve Reenskaug has said that the architecture is key to a good human/computer interface.
Now the team thinks they finally are in good shape. They are eager to go into their fourth release, which is supposed to support a wide range of new functionality. They find, again and again, the same kind of crosscutting problems as they had observed in the very early problems with User Stories interfering with each other. Everything seems to require coordination between a large number of objects, and the developers get the feeling that everything is becoming global. We have a look at the changes they are making: none of them are well encapsulated or localized, because their functional decomposition structure cuts across the functional decomposition structure inherent in the architecture. The architecture has not been partitioned according to basic business structures,
12See Reenskaug, and Coplien, “Things your mother didn’t tell you about architecture and GUIs,” ROOTS 2007, 27 April 2007, Bergen, Norway.
which would support evolution gracefully. By this time, the competition has gained so much market share that they can afford to buy out our company. They do. They talk to the consultants who have been there and decide that a major training effort is in order. They have many risks they must avoid, another one of which is:
1O ver time, the same TDD practices that drive a design away from supporting usability also drive it away from architectural soundness.
And again, the solution is:
9Don’t drive your architecture with testing. Drive it with lightweight domain analysis, and enough up-front design so that you can be
confident about the structure of the GUI and the maintainability of the architecture. Start just with abstract base classes and flesh them out as
Use Cases come along.
So now we’re working for the competition and we gain some insight into what they’re doing right. They are following most of the suggestions above. These boil down to some simple principles:
9Do lightweight up-front architecture
9Use Cases, not User Stories
9Drive tests from Use Cases rather than from developer intuition. Test developer code against independently developed tests as soon as both
are available.
Pretty simple principles. We find that they have lower bug density than we do. And, in fact, they have a strongly disciplined manner of class design. Once their classes are designed, using input from domain experts and usability folks, they attach pre- and post-conditions to the methods and assert class invariants for each instance. To do so sharpens their thinking, and does so in a much more formal way than TDD ever was able to do. To this end, the team was using macros; in Eiffel or in Spec#, you find them directly supported in the language.
The developers told the boss that this was a good idea. First, most tests only reach in and evaluate results for a specific, small set of values. Assertions can be set up to express entire sets of values, or value ranges, or arbitrarily complex business rule invariants that must always be true. System testing not only provides inputs and looks for correct outputs, but it also exercises all of these built-in assertions that look for additional invariants that derive indirectly from the requirements. The developers furthermore thought that it would be a good idea to leave the assertions in the code in the field, either to drive recovery action or to print out a message that the customer should contact customer service to report a bug. But the boss was uncomfortable with this, and told the developers not to do this. We don’t want our code failing in the field; it should continue to run. Even when admonished that continued operation in light of a failed invariant renders the program’s results invalid, and that it would be better to stop the program than to silently corrupt the client data, the boss stood his ground. The overtaking company’s management discovered his reaction and re-assigned him to staff a telephone in Customer Service.
This leads us to eleventh risk:
1E xhaustive testing is impossible, and you cannot test quality into a product. Forward-engineered spot checks do not constitute adequate
testing, and in fact their value is very low.
This is actually not a risk, since a risk is a bad thing that might happen. This is a constraint, a problem that always exists and which smart teams must solve. They can solve it as follows:
9Use invariants and assertions that formally tie to the user needs as they are understood. While total formal program proving is a long way off, it is better to get the broader coverage that invariants and assertions can
give you than to use the spot-checking of a unit test.
9Don’t forget code inspections—one of the most cost-effective bug-spotting techniques we’ve got.
9If you’re pairing, you already have four eyes looking at every line of code, and that will help your quality immensely.13 Change pairings
13See, for example, Laurie Williams, Pair Programming Illuminated.
frequently so you don’t get into mind-lock with each other. And
remember that even Pair Programming is no substitute for good design.
We know that this article has been about TDD and that TDD is not a testing
method, but a design method—that it is the main testing focus on many projects to the contrary not withstanding. But just in case you were interested in testing:
9DON’T NEGLECT SYSTEM TESTING.
Unit testing can help, and tests can play a role in sharpening one’s thinking—but not as most people practice TDD, and certainly not as the consultants teach it in the conference tutorials.
Some Final Lessons to be Learned
There is hope. Those who live at the leading edge of the curve with healthy
skepticism and long hindsight are offering healthy alternatives. Many of the
recommendations from above—a few more, a few less—can be found embodied in Behavior-Driven Development (BDD) as advocated by Dan North. BDD is a
more sober and sane approach that integrates testing and development—not as a way to supplant careful structuring, but as an audit on how the system meets
end user needs.14
We are seeing other sound ideas that return to solid principles of quality-
oriented development, such as Bertrand Meyer’s Contract-Driven
Development.15 The knee-jerk reactions that took place in response to overly
heavyweight interpretation of their principles are extreme, but are done absent
responsible reasoning. Instead, follow the proven practices as described in these articles. They can be summarized as follows: testing is an integral part of
software development, and requires the same careful attention to systematic
design as writing the code itself. Just like the code, the tests must be designed;
however test design is essentially different from code design. One cannot simply augment cowboy coding with cowboy testing, and expect to produce a quality
product.
14See Dan North, “BDD – The Agile Evolution,” Expo-C, Gothenburg, Sweden, 24 April,
2007.
15See Bertrand Meyer, ?resund Complete, Malm?, Sweden, 10 May, 2007.
Acknowledgements
Many thanks to Stine Laforce, Rex Black, Jeff Sutherland, H?kan Reis, and Magnus M?rtensson for comments, criticisms, and encouragement.
雅思历年真题口语题目汇总 version 01old person describe an old man influenced you 1.who was he 2.when did you know him 3.what he did and explain why he influenced you part3 1.老人的经验有什么问题存在? 2.喜欢什么艺术品? 3.给老人拍照片时候注意什么呢? 4.你们国家对老年人是什么态度？ 5.你认为这个社会在哪些方面对老年人不太好？ 6.老人在你们家有什么影响？ 7.你认为老年人在看问题的时候跟年轻人有什么不一样？ 8.他们对大家有什么影响？ version 02 city 1.where it is located? 2. what special for you? 3. why you want to stay there? part 3 1.please compare 100 hundred years old city and modern city and what predict about the city in the future. 2.上海是个怎样的城市 3.都有那些著名建筑
4.你想为这个城市做些什么？ 5.有哪些现象有待提高或者那些提倡 version 03 room part2: 1.what's your favorite room in your home 2.what it likes you live 3.what you do in the room normally and explain why you like it part3: 1.你认识你的邻居吗？ 2.城市里的房子和乡村有什么不同？ 2003年9月换题后的口语topic Old person Describe a older person you know You should say:Who he or she is How you know him or her How he or she is And explain what infection he or she give you and in what aspect Further question： 1、你们国家对老年人是什么态度？ 2、你认为这个社会在哪些方面对老年人不太好？ 3、老人在你们家有什么影响？ 4、你认为老年人在看问题的时候跟年轻人有什么不一样？ 5、他们对大家有什么影响？
Google搜索从入门到精通 v4.0 （一） 1、前言 我是在2000年上半年知道GOOGLE的。在这之前，我搜索英文信息通常用AltaVista，而搜索中文信息则常用 Sina。但自使用了GOOGLE之后，它便成为我的Favorite Searchengine了。这也得感谢新浪网友曹溪，因为当初正是因为他的大力推介，才使我识得了GOOGLE。 记得1996年夏季的时候，当我第一次接触Internet，便被扑面而来的魔力征服了。那种天涯咫尺的感觉，真是妙不可言。在经历了疯狂的WWW冲浪和如痴如醉的BBS沉迷之后，我意识到Internet对我影响至深的还是在于学习方式的变迁。 如何来描述这种变迁呢？以前的学习，一般需要预先在肚子里存储下足够的知识，必要时，就从海量的信息中提取所需的部分。这种学习方式造就了很多“才高八斗，学富五车”的大才子。但是，到了信息领域大大超出“四书五经”的新时期，预先无目的的吞下海量信息的学习方式就有些不合时宜了。比方说，我们到了大型的图书城，往往有一种不知所措的感觉。旧有的学习方式需要变更以适应这个信息爆炸的年代。目的明确的去学习，即先知道要学什么，然后有目的的去寻找答案，这种方式看上去更加有效率。我不妨把这称为“即学式”，相应的，旧有的称为“预学式”。不过，“即学式”的实施是有前提的。首先，要求学习者拥有一个包罗万象的信息库，以供随时抽取各种目的信息；其次，是需要一个强劲的信息检索工具，以便高效率的从信息库中提取信息。很明显，Internet可以充当那个海量的信息库，而搜索引擎，则正是寻找光明之火的绝好工具。 “公欲善其事，必先利其器”。Internet只有一个，而搜索引擎则有N多个。有搜索高手说，所谓搜索，就是“在正确的地方使用正确的工具和正确的方法寻找正确的内容”。但是，对于普通人而言，掌握诸多搜索引擎的可能性似乎不大。用一两个相对强劲的具代表性的工具达到绝大多数搜索目的更为人们所迫切希望。不同的时期，涌现出不同的强者。就目前而言，我们非常幸运的有了： *****GOOGLE***** 2、摘要 本文简要的介绍了GOOGLE的历史和特点，GOOGLE的基本搜索语法和高级搜索语法，GOOGLE的特
白板课件的制作 各位老师下午好，很高兴能有一个和大家一起学习交流的机会，现将自己平时运用电子白板的一些心得，在这里作一个交流，期待大家能够互相学习，共同提高电子白板的运用水平。 电子白板课件较之演示文稿（ppt）制作出来的课件更具灵活性和互动性,以我的数学白板课件《面积的认识》为例来讲解一下白板课件的制作方法. 一、白板课件的制作方法 1、制作课件封面 (1)电子白板课件的制作比ppt课件制作更加简单快捷，电子白板软件的文字编辑功能极差，在ppt软件的文本框中输入所需文字进行编辑，设置好格式，将其另存为png图片（png格式图片背景是透明的）。 (2)对于一些图形素材也可以用ppt软件制作完成后，按照上述方法将其另存为png图片。 2、新建图片页，插入图片或文字。 3、设置动画，保存后再预览。预览后退出不保存。 4、删除页面。 5、利用智能笔工具，在白板上呈现的实物图周边画出轮廓，沿着物体的外沿来画移走实物后，留下的就是轮廓。 1、给汉字注音 2、汉字笔画
3、Flash相册制作 4、文件的导入 二、活用背景颜色，实现遮掩效果 电子白板软件和ppt的使用操作基本相同，但在表现形式上，前者是手动演示，后者则是自动演示。代表着两种不同的教学理念，电子白板代表的是交互、即时生成的课堂，ppt代表的是演讲风格的教学。 1.制作一个与白板背景颜色相同的色块遮住标题、问题或概念等文字，用拖放功能将色块慢慢移开，从而实现显示文字的动态效果。当然此法也可锁定遮挡色块，利用拖放文字的方式实现切入的效果。 2.制作文字标题，并将其隐藏到白板的角落，教学时用白板笔将其拖入，从而实现类似ppt切入的效果。 三、掌握链接功能，实现页面跳转 电子白板软件的插入超链接功能不仅可以实现页面的跳转，还可以实现网页及文件的链接打开，非常容易实现各种资源素材的显现。 四、借助工具软件，博采众长. 在白板课件制作的过程仍然需要借助第三软件来实现一些补充功能，以期达到事半倍的效益。如，许多老师希望能够用电子白板软件实现一组图片自动切换，配以背景音乐，创设情境，其实电子白板软件很难实现这一效果。这里我们可以借助flash gallery factory这款flash相册制作工具软件，把图片变换成绚丽多彩的flash幻灯片和
雅思为各位考生推荐复习材料-剑 5 口语 Test4 Part3-Purpose of festivals and celebrations；需要本教程其他单元口语范文的考生请点击：剑 5 口语Test3 Part1-Entertainment；剑5 口语 Test3 Part2-Describe one of your friends；剑5 口语 Test3 Part3范文-Qualities of Friends。 PART 3: Purpose of festivals and celebrations Q: Why do you think festivals are important events in the working year? Answer: Yeah. It’s very important for two reasons. For the country, it’s a time to remember our cultural origin and our historical past. The whole country celebrates our root and it’s very inspiring. We become so proud of our past. I guess that’s why festivals are important. For the individual, festivals give us a chance for relaxation as we often have a few days off. It’s a time of fun, meeting friends, entertainment. So after that we feel like a new man. In a sense, holidays restore our balance between work and leisure. That’s also why we need festivals for China. Q: Would you agree that the original significance of festival is often lost today? 构思: 节日的初衷: 庆祝传统, 承上启下, 结束也是开始 现在的节日: 人们繁忙, 感觉不到开始和结束的意义, 过完节,马上就再次投入到工作中, 有些单位甚至连节假日都加班. 人们也不在那么感动传统,倒是好好的利用节日放松了一下,
雅思历年真题口语题目汇总 version01old person describe an old man influenced you 1.who was he 2.when did you know him 3.what he did and explain why he influeced you part3 1.老人的经验有什么问题存在? 2.喜欢什么艺术品? 3.给老人拍照片时候注意什么呢? 4.你们国家对老年人是什么态度？ 5.你认为这个社会在哪些方面对老年人不太好？ 6.老人在你们家有什么影响？ 7.你认为老年人在看问题的时候跟年轻人有什么不一样？ 8.他们对大家有什么影响？ version02city 1.where it is located? 2.what special for you? 3.why you want to stay there? part3 1.please compare100hundred years old city and modern city and what predict about the city in the futu re. 2.上海是个怎样的城市 新东方批改网（https://www.doczj.com/doc/883644045.html,）,在线雅思作文批改，雅思口语批改。语法纠错、恶补，制定考试计划，
3.都有那些著名建筑 4.你想为这个城市做些什么？ 5.有哪些现象有待提高或者那些提倡 version03room part2: 1.what's your favorite room in your home 2.what it likes you live 3.what you do in the room normally and explain why you like it part3: 1.你认识你的邻居吗？ 2.城市里的房子和乡村有什么不同？ 2003年9月换题后的口语topic Old person Describe a older person you know You should say:Who he or she is How you know him or her How he or she is And explain what infection he or she give you and in what aspect Further question： 1、你们国家对老年人是什么态度？ 2、你认为这个社会在哪些方面对老年人不太好？ 3、老人在你们家有什么影响？ 新东方批改网（https://www.doczj.com/doc/883644045.html,）,在线雅思作文批改，雅思口语批改。语法纠错、恶补，制定考试计划，
?法磊推荐的书，网站 ●英语写作能力：《高级英语写作手册》（英文版北京外国语大学出版社） ●双语能力：英汉对照读物 ●做个知识渊博的杂家：1）先去国内各大门户网站了解一下新闻，再去 China Daily,新华网英文版了解英文的表达法，可以学到本土特色东西的表 达法。 2）浏览国外新闻网站，就同一个话题，摘取一段换，揣摩表达方法。 3）浏览论坛，如翻译中国，译网情深，https://www.doczj.com/doc/883644045.html,/ 4）《中国翻译》 5）http://blog.hjenglish/wuzhongdong北外教授博客 6）《Google 从入门到精通》 ?翻译路上的交通证（考证一方面是一种凭证，另一方面也是一种 学习过程） ●上海高级口译证书和CATTI笔译二级证书 ●参加比赛：韩素音青年翻译奖 CCTV希望之星英语风采大赛 ?翻译路上的工具 ●搜索引擎：1）缩略语的搜索：缩略语+所属范畴 专有名词的搜索：如，中国银行业监督管理委员会+bank 2）名言名句的翻译要事先搜索是否有更地道的翻译 3）对于不确定的搭配可利用搜索引擎搜索，如果超过20个网页有这样的 表达，且大多数为外国网站，则可以运用 4）小语种的翻译可以借助先转换为英语再转换为中文（资料少的情况下） 语种互译网站：https://www.doczj.com/doc/883644045.html,/translate-t ●TRADOS软件 ●专业术语在线词典：https://www.doczj.com/doc/883644045.html,/ ●word,excel,ppt,pdf，autocad(工科翻译)的熟练使用，包括排版 ?翻译中的思维与方法 ●以段为单位，理解大意后，再翻译每个句子，然后再从整段出发修改 句子。翻译的句子要考虑阅读者的思维习惯。 ●只要保证语义不变，句子形式、语法结构都可以改变。 ●翻译中的修改，1）先修改低级错误，如标点，错别字 2）对照原文逐句看翻译正确与否 3）抛开原文，看译文是否通顺 4）再对照 5）搁置几天后再修改 ●翻译初期，要先做英译中，学学正确的英语表达方法。
【雅思口语预测】雅思口语话题题库范文 雅思口语精准预测刘薇简介环球雅思北京学校副校长最受欢迎口语教师授课时激情中透着温婉幽默里渗入励志秉承让学生 "轻松复习事半功倍"的教学理念。 从事雅思教学多年北京大学传播学硕士曾学术访问哈佛大学 耶鲁大学等世界顶尖名校。 著作《雅思九天口语高分之路》、《剑桥雅思全真试题原版解析8》。本月预测重点本预测适用于xx年4月雅思考试超高频和重回题库考题、一级重点、都是重点类别需要考生准备细致答案。二级重点考生考生准备思路即可。 Part 1 分类汇总一基本信息类 1. Name 什么名字，中文名含义，未来换吗 2. Study or work 上班还上学上学问专业或最喜欢学科上班工作内容，参加过培训吗，未来换工作吗 3. Hometown 家乡哪里，有什么特别的地方，未来想居住的地方 4. Weather 喜欢什么天气家乡天气，家乡天气今年的变化 5. Family 家庭情况，家庭时间如何度过，全家人喜欢一起做什么二衣食住行类 1. Living 住flat还是house，最喜欢的房间，如果重装修会怎么做 2. Building 喜欢什么建筑，你们国家的人更喜欢传统还是时尚建筑，未来建筑的发展 3.
Countryside 喜欢郊区吗，郊区与城市的区别，什么人喜欢郊区 4. Transport 家乡交通特点，公共交通和私人交通的优缺点，未 来如何改善 5. Boating 划过船吗，坐过船吗，好处，你们国 家水运多吗 6. Clothes and fashion 喜欢什么衣服，喜欢时 尚吗，时尚对生活的影响 7. Bags 平时背包包吗，什么类型的 宝宝，知道哪些包包，丢过包包吗 8. Keeping healthy and fit 如何保持健康，如何保持身材 9. Daily routine and favorite time in a day 典型的一天，一天中最喜欢的时间段 10. Sleeping 几点睡几点起，睡不着怎么办，如何培养好的睡眠习惯 三娱乐休闲 1. Music 喜欢什么类型音乐，喜欢在家听还是concert hall。会乐器吗，什么乐器。 2. dancing 会舞蹈吗，中国人喜欢什么舞蹈，传统舞蹈得到了 传承吗 3. photography 喜欢摄影吗，喜欢给别人拍还是别人 给你拍，喜欢收藏照片吗 4. painting 会画画儿吗，小孩子学 习绘画的好处，有什么绘画技巧吗 5. sport 最喜欢什么运 动，好处 6. museum 喜欢去博物馆吗，好处，博物馆该收费吗7. leisure and relaxation 喜欢什么休闲活动，跟谁，在哪 儿，好处，中国人都喜欢什么休闲 8. weekends 如何度过周 末，周末加班吗，老板应该给发工资吗 9. postcards 喜欢 ___吗，发给别人或者收到过吗，跟email的区别 10. public park 喜欢去公园吗，做什么，应该有更多公园吗四科技生活
剑桥雅思口语真题解析 Part 1: 1.1姓名 1. What’s your full name? 2. Can I have your name, please? 3. Are there any special meanings of your name? 4. Do you like your name? Why? 5. Do Chinese people like changing their names? 6. What kind of people in China like changing their names? 7. Is there any rule for Chinese people giving names to their children? 1.2故乡 My hometown is Guangzhou. It is the capital of Guangdong province in the southwest of China. It is a large industrial city. It is close to Hong Kong so a lot of the industries involve trade and retail. It is also a finance area. The people in Guangzhou are very genial and helpful, also are very easy to get around. If you lose your way and ask someone, he will give you the direction immediately, he can also give you a hand if you are in trouble. By the year 2011, it is believed that my hometown Guangzhou has become the economic center of China. 2. Where is it located? 3. How about the climate in your hometown? Which season do you like? In my hometown Guangzhou, the four seasons are not evident, which only has spring and summer. It is too hot in the summer and it is also humid in the winter. I like summer better, for we will go swimming and start our outdoor activities in the summer, it gives us pretty environment, which full of various kinds of colors. Another reason is that it is suitable for traveling around. 4. How about the people in your hometown? The people in my hometown Guangzhou are very genial and helpful, also are very easy to get around. People will always give you a hand with things. If you lose your way and ask someone, he will give you the direction immediately, he can also give you a hand if you are in trouble. 5. What do most people do in your hometown? 6. Oh yes. Even though Guangzhou is very modern, it has some interesting temples and streets. There is one called the Temple of Six Banyan Trees and it was built about 1500 years ago. There is also a famous cultural and commercial street in Guangzhou called Beijing Road. In this street, you can not only see a historic exhibition about different years roadbed, which has more than thousand histories, but also has many business shops sale almost all kinds of things. Besides, you can taste traditional snacks and refreshments or experience temples with /unusual special architectural style nearby. Anyway, it is an interesting place so worth to visit! 7. How about the style of the building in your hometown? 8. What is one of the greatest changes having taken place over the years? 9. What problems still exist in your hometown? 10. How to improve the situation in your hometown? 11. Where is Chinese population mainly distributed? 12. What changes have occurred in people’s dwelling? 1.3学习 1. Are you an employee or a student? (Are you working or studying?) 2. What is your major?
法律英语学习经验 1、法律专业且英语较好，或英语专业，掌握一定法律知识。个人觉得前者比后者更容易学好法律英语。本人属于前者。 2、学习外语最重要的是工具书，学习法律英语也不例外，拥有一本好的工具书是非常重要的。下面推荐几本很不错的工具书。 （1） Black’s Law Dictionary (7th版) 布莱克法律辞典（第七版），1999年出版，共1738页，英文原版，价格697元，网络上有卖的。大些的法律书店也有卖的。 （2）牛津现代法律用语辞典 法律出版社引进的英文原版，共953页，价格170元。该书主要是对一些法律词语进行了语法、语义上的分析，比如同义词、近义词比较，一些词语的拼写不同等。 （3）元照英美法词典 价格是380元，质量在国内同类工具书中算是最好的，但也存在一些错误和不足。详见本论坛帖子《元照英美法词典》求疵。 以上三本工具书是我用过的，都很不错。下面是我没用过的，但其他专家推荐的： （4） Oxford Law Dictionary 牛津法律词典 （5） Merriam-Webster’s Law Dictionary 1996年版，16美元。 此外陈忠诚所著《英汉汉英法律用语辩证词典》也不错，有真材实料。至于其他的英汉、汉英法律辞典，最好别买，大概都是剪刀加浆糊的产物；人云亦云，有很多错误的，误人子弟。 宋雷也主编过一大部头的、与元照同样规模的法律英语词典，其内容还未仔细研读，在此不作评论。 如果大家没钱，可以用网上词典，在此推荐https://www.doczj.com/doc/883644045.html,，很不错的词典搜索引擎。
3、多读英文原版教材和文章，理解词的具体运用和英美法律制度，扩大词汇量。 4、多看他人有关文章、著作及有关法律的正式英文译本，去伪存真。前提是你的知识量足够大，能一眼看出其真伪对错。《中国翻译》、《上海翻译》、《中国科技翻译》经常刊载法律翻译方面的文章，可惜多为泛泛之作，少见精品。 关于如何学好法律英语，我的经验大体就这些。但如果要作一个好的法律翻译，这些显然是不够的，这又是另外一个话题了。 关于如何学好法律英语，每个人的基础不一样，学习的习惯也不一样，所以很难有一个"万精油"的方法。 这里仅有几点个人经验，供参考： 1.坚持看原版的法律新闻，最好的地方如下： https://www.doczj.com/doc/883644045.html,/ ，如果上网方便，最好每天去一次，哪怕是时间只够把新闻标题看完…… 2.坚持用原版的法律词典，最好的当然是black’s law dictionary,不过，这两个地方的法律词典也不 错:https://www.doczj.com/doc/883644045.html, ,https://www.doczj.com/doc/883644045.html, .当然，刚开始用原版的法律词典可能有些不习惯，从长远来看，这是非常有好处的。 3.坚持读原版的法律书籍， 4.坚持听原版的法律节目，cnn和abc及bbc每周都有与法律有关的节目，这些节目网上也可以收听，只不过要通过代理服务器，还好，这个网站可以访问：https://www.doczj.com/doc/883644045.html, , 只是这里的节目没有原文对照，听起来有些难。还有一些：坚持分析原版的案件,坚持用英语写读书笔记和日记，坚持用英语思考，用英语和朋友，和
交互式电子白板课件设计与制作 第一讲：多媒体课件概述 学习目标： 1. 明确多媒体课件的定义、类型和特点 2. 识别多媒体课件的基本组成部分 3. 描述课件组成部分的内容和作用 4. 运用课件组成部分的设计要求 1.1定义 多媒体课件，也被称为多媒体教学软件、多媒体教材，是根据课程教学大纲的培养目标要求，用文本、图形、图像、音频、视频、动画等多种媒体与超文本结构去展现教学内容，并且用计算机技术进行记录、存储与运行的一种软件。 1.2课件优点 ●有助于教：能够为学生提供一个学习情境，协助教师完成预定的教学任务。 ●有助于学：以多变易用的形式展现出传统模式难以表达的抽象事物，使学习者获 得形象的多重的信息刺激，从而提高教学质量和学习效果。 1.3课件缺点 （1）课件的专用性 （2）课件的不可重组性 （3）课件对教材的依赖性 1.4课件类型 1. 课堂演示型 2. 操作与练习型 3. 指导型 4. 资源型 5. 模拟型 6. 教学游戏型 第二讲多媒体课件制作一般流程 多媒体课件是一种多媒体技术在教学上的应用软件，它的设计与其它软件设计相同，主要经过需求分析、教学系统设计、脚本编写、课件编制、测试评价等过程。 2.1需求分析 1．内容分析 在多媒体课件开发的第一阶段，首先要明确教学内容，明确教学中的重点和难点，明确哪些可以替代传统教学，明确哪些可以用课件提高教学效率。 2．使用对象分析 不同年龄阶段的学生其认知结构有很大的差别，使用对象分析就是对学习者特征的分析，它包括学习者的年龄、受教育水平、阅读能力水平、动机水平、原有知识结构和掌握计算机的水平等。 2.2教学系统设计 教学系统设计是开发过程中最重要的一环，它是形成多媒体课件设计总体思路的过程，决定了后续开发的方方面面。
雅思为各位考生推荐复习材料-剑11口语 Test4 Part3-Different types of TV programmes,需要本教程其他单元的口语范文，请点击：剑11口语 Test3 Part1范文-Photographs；剑11口语 Test3 Part2范文-weather；剑11口语 Test3 Part3范文-Types of weather。 Discussion topics: Different types of TV programmes Example questions: What are the most popular kinds of TV programmes in your country? Why is this? Do you think there are too many game shows on TV nowadays? Why? Do you think TV is the main way for people to get the news in your country? What other ways are there? TV advertising Example questions: What types of products are advertised most often on TV? Do you think that people pay attention to adverts on TV? Why do you think that is? How important are regulations on TV advertising? 题目一：What are the most popular kinds of TV programmes in your country? Why is this? 1.结构提示： There are so many kinds of TV programmes are popular in my country The and are very popular TV programmes in my country for they targetas the main audience 2.要点提示： TV play/TV series/ups and downs in the plot/kill time/ amusing/down to earth/depict common people’s life 题目二：Do you think there are too many game shows on TV nowadays? Why? 1.结构提示： Exactlyhttps://www.doczj.com/doc/883644045.html,/ielts/cb11/ I don’t make a comment because I never see
剑桥雅思9口语真题+解析Test3-Part3 摘要：剑桥雅思9口语真题+解析Test3-Part3，剑桥雅思9Test3口语Part3讨论话题举例：Reasons for daily travel，有需要的同学抓紧时间下载吧! Discussion topics: Reasons for daily travel Example questions: · Why do people need to travel every day? 为什么人们每天都需要出行? 笨鸟雅思口语名师点题 本题询问人们为什么每天穿梭于各地。通常针对询问people的问题，可以相应列举出不同人群，如上班的人、上学的人、走亲访友的人、旅游的人等，同时针对某类人群适当进行拓展。 高分示例 People need to travel for lots of different reasons. Almost everybody has to travel to work, so they can earn money and provide for their families. If a person is lucky, then they will live very close to the place where they work, so they can travel on foot or by bicycle. Sometimes, however, people live very far away, so they must travel by bus, train, car, or even sometimes by plane or boat! Lots of people also travel to see friends and family members, who might live in a different city, or even a different country. But often people just like to travel for fun, to go to somewhere new, or to see a famous tourist site or place of natural beauty. 参考译文 人们有各种各样的理由来来往往。几乎每个人都要去上班，这样才能赚钱养家。幸运的人住的地方离工作单位很近，可以步行或者骑车去上班。但是，有时候，住的地方比较远的人就必须坐公交车、坐火车、开车，甚至坐飞机、坐船去上班。大部分人都会去异地甚至异国拜访朋友、看望家人。但是人们经常是出去玩，去探索新的地方，去看看著名的景点，去看看自然美景。 亮点表达 earn money 赚钱 tourist site 旅游景点 provide for 供养
DOCTYPE和字符集 在2.1.2节中通过新老DOCTYPE的对比，读者可以清晰地看到HTML 5在精简旧有结构上做出的努力。DOCTYPE在出现之初主要用于XML中，用作描述XML允许使用的元素、属性和排列方式。起初HTML借鉴了XML中DOCTYPE的使用方法，并赋予了新用法，如大家熟知的触发浏览器的标准模式。假使在制作一张页面时，没有设定DOCTYPE，则浏览器会以怪异模式状态进行处理（即Quirks模式），该模式与标准模式在盒模型、样式、布局等都存在较大差异。因此，DOCTYPE在制作页面时是不可或缺的部分。 在上一版本HTML 4标准中，DOCTYPE被分为3种模式： ?严格模式，即严格遵循W3C标准的模式，代码格式如下： [html]view plain copy 1. ?过渡模式，包含了W3C标准的内容，同时还可以使用不被W3C推荐的标签，如font、b等，而且不可以使用框架元素（即frameset元素），代码格式如下： [html]view plain copy 1. ?框架模式，可以使用框架元素，其他与过渡模式相同，代码格式如下： [html]view plain copy 1. 提示：旧有的HTML关于DOCTYPE标准，读者可以参看W3C官方文档说明，网页地址：https://www.doczj.com/doc/883644045.html,/TR/1999/REC-html401-19991224/struct/global.html#h-7.2。虽然之前版本的HTML对DOCTYPE做了重重规定，但真实情况却是浏览器会尽最大的可能渲染
剑7雅思口语模板Test4Part1-Traveling to work or college 剑7雅思口语模板Test4Part1： The examiner asks the candidate about him/ herself, his/ her home, work or studies and other familiar topics. 1. Q: How do you usually travel to work or college? Why? A: Most of time, I take the bus or the subway to go to work. There are a lot of buses coming and going, and I don’t have to wait for a long time. 2. Q: Have you always traveled to work/college in the same way? Why / Why not? A: No. If I am in a hurry or when it rains, I will take the taxi. In my city, it is really difficult to get on a bus in rainy days. If I don’t want to be late, taking the taxi is the best option. 3. Q: What do you like about travelling to work/college this way? A: I like taking the taxi because it is better, and I don’t have to be crammed in the sardine-like bus. As we know, the buses tend to be stuffy in summer time，and I don’t feel comfortable when there are too many people around me. 4. Q: What changes would improve the way you travel to work / college? Why? A: The change that we are waiting for is to have more buses during rush hour. If there are more buses, and they come every few minutes, people don’t have to struggle to get on the bus. 口语考官答案 Travelling to work or college 1. Q: How do you usually travel to work or college? Why? A: I travel to work by bus because it is convenient and cheap. 2. Q: Have you always travelled to work/college in the same way? Why? / Why not? A: Metro, I have always traveled to work like this because it is so efficient, quick and cheap. Or A: No, I used to travel to work by motorbike because I didn’t live near a subway. 3. Q: What do you like about travelling to work/college this way?
如何在白板中打开PPT 在进行PPT的操作前, 请老师们确定白板软件的服务程序已经启动,电脑右下角出现如下快捷工具栏: 操作步骤: 1, 在电脑状态下,打开一个PPT文件. 2, PPT文件打开后,选择放映方式,在PPT上方的工具栏中找到"幻灯片放映"→观看放映,让电脑全屏播放PPT文件. 3, 提起智能笔架上的笔,白板下方出现一行工具栏,如下: 这时可以进行书写批注,选择笔,笔的颜色,笔宽,漫游,插入图形,索引页等功能. a. 翻页:就点击当前页面上左上角的翻页图标 ; b. 漫游:如果书写空间不够,可以使用漫游,这样就可以在页面旁进行更多的书写批注. c. 浏览图片:点击"插图"—浏览图片—在图库对话框点击搜索—找到文件的位置—点击要浏览的图片—拖动; d. 插入音视频:点击"插图"-插入音视频-在对话框中找到文件的位置-点击要插入的音视频文件-在板面上拖动; (不要图片或音视频时,使用橡皮擦,就可以将他们轻轻擦掉了.) e. 索引页:我们在PPT文件上的修改能够在索引页中找到,原有的PPT文件在电脑状态下并没有被修改. f. 修改后的PPT文件的保存:点击开始菜单,在弹出的菜单里选择"输出",可以保存为图像格式,PPT格式,PDF格式,HIML格式;选择"保存",则保存为系统默认的WBS格式,即白板格式. 在课堂上你可以利用教学电子白板配套的电子软件，对原有的课件可用不同颜色、不同笔型的笔迹进行标注讲解，可以随心所欲的在上面写、画、插入视频剪辑图片、可以改变背景图和颜色、可以进行放大和缩小等等!如此众多的功能，在提升教学效率的同时，增加了学生对课程内容的趣味性。 现将自己平时运用电子白板的一些心得，在这里作一个交流，期待大家能够互相学习，共同提高电子白板的运用水平。 学会自制课件电子白板最主要的性能特点之一就是其电子课件的交互性，因此，我们要改变传统PPT电子课件的制作方法，综合利用一切资源，包括电子白板软件配套的教学资源库，以及网络资源，利用，图文并茂的PPT 课件，在加上必要的动画视频等等，丰富我们的教学电子课件。为了更好地让白板服务于我们的课堂教学，就需要我们能因课置宜地设计一些课件，帮助我们来突破一些教学上的重难点。如何利用好电子白板软件，如何制作丰富的电子课件是我们运用教学电子白板的第一步。 巧用工具栏 在从“开始”按钮展开菜单后，有遮屏，聚光灯等选项，遮屏和聚光灯等是电子白板的一些特殊功能，将