Listing 1 - 10 of 15 | << page >> |
Sort by
|
Choose an application
The groundbreaking book Design Driven Testing brings sanity back to the software development process by flipping around the concept of Test Driven Development (TDD)—restoring the concept of using testing to verify a design instead of pretending that unit tests are a replacement for design. Anyone who feels that TDD is “Too Damn Difficult” will appreciate this book. Design Driven Testing shows that, by combining a forward-thinking development process with cutting-edge automation, testing can be a finely targeted, business-driven, rewarding effort. In other words, you’ll learn how to test smarter, not harder. Applies a feedback-driven approach to each stage of the project lifecycle. Illustrates a lightweight and effective approach using a core subset of UML. Follows a real-life example project using Java and Flex/ActionScript. Presents bonus chapters for advanced DDTers covering unit-test antipatterns (and their opposite, “test-conscious” design patterns), and showing how to create your own test transformation templates in Enterprise Architect.
Computer programming. --- Computer software -- Development. --- Computer software -- Testing. --- Engineering & Applied Sciences --- Computer Science --- Information Technology --- Computer Science (Hardware & Networks) --- General and Others --- Application software --- Development. --- Development of application software --- Computer science. --- Computer Science. --- Computer Science, general. --- Programming Techniques. --- Computers --- Electronic computer programming --- Electronic data processing --- Electronic digital computers --- Programming (Electronic computers) --- Coding theory --- Informatics --- Science --- Programming --- Software engineering. --- Programming Languages, Compilers, Interpreters. --- Software Engineering/Programming and Operating Systems. --- Computer software engineering --- Engineering --- Programming languages (Electronic computers). --- Computer languages --- Computer program languages --- Computer programming languages --- Machine language --- Languages, Artificial
Choose an application
Use Case Driven Object Modeling with UML: Theory and Practice shows how to drive an object-oriented software design from use case all the way through coding and testing, based on the minimalist, UML-based ICONIX process. In addition to a comprehensive explanation of the foundations of the approach, the book makes extensive use of examples and provides exercises at the back of each chapter. This book leads by example. It demonstrates common analysis and design errors, shows how to detect and fix them, and suggests how to avoid making the same errors in the future. The book also encourages you to examine its UML examples and to search for specific errors. You'll get clues, then later receive the answers during review sessions toward the end of the book.
UML (Computer science) --- Unified Modeling Language (Computer science) --- Computer software --- Modeling languages (Computer science) --- Object-oriented methods (Computer science) --- Development --- Information Technology --- Software Engineering --- Approche orientee objet (Informatique) --- Cas d'utilisation (Ingenierie des systemes) --- UML (Informatique) --- 681.3*D23 --- 681.3*D2 --- 681.3*D23 Coding: pretty printers; program editors; reentrant code; standards (Softwareengineering) --- Coding: pretty printers; program editors; reentrant code; standards (Softwareengineering) --- 681.3*D2 Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Computer science. --- Software engineering. --- Programming Languages, Compilers, Interpreters. --- Software Engineering/Programming and Operating Systems. --- Informatics --- Science --- Computer software engineering --- Engineering --- Programming languages (Electronic computers). --- Computer languages --- Computer program languages --- Computer programming languages --- Machine language --- Electronic data processing --- Languages, Artificial --- 681.3*D32 --- 681.3*D32 language classifications: applicative languages; data-flow languages; design languages; extensible languages; macro and assembly languages; nonprocedural languages; specialized application and very high-level languages (Programminglanguages) --- language classifications: applicative languages; data-flow languages; design languages; extensible languages; macro and assembly languages; nonprocedural languages; specialized application and very high-level languages (Programminglanguages) --- Compilers (Computer programs). --- Compilers and Interpreters. --- Software Engineering. --- Compiling programs (Computer programs) --- Computer programs --- Programming software --- Systems software
Choose an application
Cutting through the hyperbole with a no-punches-pulled deconstruction of extreme programming the authors separate the agile from the fragile and reveal which XP techniques are useful and which are of questionable value.
eXtreme programming --- Programmation extrême --- XP (Computer science) --- Computer programming
Choose an application
Choose an application
In this chapter we illustrated how to drive unit tests from a software design, identifying test scenarios in a systematic way that ensures the code is covered in all the right places. We also illustrated the use of stunt services and mock objects to isolate the code being tested; finally, we discussed driving unit tests deeper into algorithmic code that may benefit from finer-grained testing. Is there a way to get 95% of the benefit of the comprehensive unit testing we did in this chapter with significantly fewer tests? In the next chapter, we'll show how to do exactly that with controller tests. As you'll see, unit tests do have their place, but controller tests can often represent a smarter, more structured approach to application testing. 136 C H A P T E R 6 ? ? ? Conceptual Design and Controller Testing As you saw in Chapter 5, unit testing doesn't have to involve exhaustively covering every single line of code, or even every single method, with tests. There's a law of diminishing returns and increasing difficulty as you push the code coverage percentile ever higher. By taking a step back and looking at the design on a broader scale, it's possible to pick out the key areas of code that act as input/output junctures, and focus the tests on those areas.
Programming --- Computer architecture. Operating systems --- Computer. Automation --- computers --- computerbesturingssystemen --- programmeren (informatica) --- programmeertalen --- software engineering
Choose an application
Extreme Programming Refactored: The Case Against XP (featuring Songs of the Extremos) takes a satirical look at the increasingly-hyped extreme programming (XP) methodology. It explores some quite astonishing Extremo quotes that have typified the XP approach quotes such as, “XPers are not afraid of oral documentation,” “Schedule is the customer's problem,” “Dependencies between requirements are more a matter of fear than reality” and “Concentration is the enemy.” In between the chuckles, though, there is a serious analysis of XP's many flaws. The authors also examine C3, the first XP project, whose team (most of whom went on to get XP book deals shortly before C3's cancellation) described themselves as "the best team on the face of the Earth." (In a later chapter, the authors also note that one problem which can affect pair programmers is overconfidence—or is that "eXcessive courage"?). The authors examine whether the problems that led to C3's “inexplicable” cancellation could also afflict present-day XP projects. In the final chapter, Refactoring XP, Matt and Doug suggest some ways of achieving the agile goals of XP using some XP practices (used in moderation) combined with other, less risk-laden methods.
Choose an application
This book describes how to apply ICONIX Process (a minimal, use case-driven modeling process) in an agile software project. It's full of practical advice for avoiding common agile pitfalls. Further, the book defines a core agile subset so those of you who want to get agile need not spend years learning to do it. Instead, you can simply read this book and apply the core subset of techniques. The book follows a real-life .NET/C# project from inception and UML modeling, to working code through several iterations. You can then go on-line to compare the finished product with the initial set of use cases. The book also introduces several extensions to the core ICONIX Process, including combining test-driven development (TDD) with up-front design to maximize both approaches (with examples using Java and JUnit). And the book incorporates persona analysis to drive the projects goals and reduce requirements churn.
Computer software --- Development. --- Development of computer software --- Software development --- Information Technology --- Computer Science (Hardware & Networks) --- Java (Computer program language). --- Software engineering. --- Java. --- Software Engineering/Programming and Operating Systems. --- Computer software engineering --- Engineering --- Object-oriented programming languages --- JavaSpaces technology
Choose an application
Matt's Preface This book illustrates how to get from use cases to working, maintainable source code in as few steps as possible . . . but without cutting the essential corners. It's also about how to minimize the amount of rework you need to do once you've gotten to source code. Learning by Doing In this book we've tried to capture the essential qualities of Doug's ICONIX training courses that is, the magic qualities of learning by doing. The ICONIX Jumpstart courses are very practical and hands-on; they draw students in by encouraging them to learn new skills by practicing, often on the real projects that they'll be returning to once the course is finished. This idea of learning by doing has long been recognized as an optimal form of education. Even at the start of the twentieth century, John Dewey, an American psychologist and edu- tional reformer, recognized that learning from experience gives rise to increasing productivity. The key is to engage the brain with practical tasks rather than to fall into the all-too-familiar study trap of rote learning. Memorizing long lists of names or API functions might help someone score highly on a test, but it isn't the same as understanding a subject in depth. For one thing, people tend not to retain information for very long if they've simply memorized it.
Choose an application
In this chapter we illustrated how to drive unit tests from a software design, identifying test scenarios in a systematic way that ensures the code is covered in all the right places. We also illustrated the use of stunt services and mock objects to isolate the code being tested; finally, we discussed driving unit tests deeper into algorithmic code that may benefit from finer-grained testing. Is there a way to get 95% of the benefit of the comprehensive unit testing we did in this chapter with significantly fewer tests? In the next chapter, we'll show how to do exactly that with controller tests. As you'll see, unit tests do have their place, but controller tests can often represent a smarter, more structured approach to application testing. 136 C H A P T E R 6 ? ? ? Conceptual Design and Controller Testing As you saw in Chapter 5, unit testing doesn't have to involve exhaustively covering every single line of code, or even every single method, with tests. There's a law of diminishing returns and increasing difficulty as you push the code coverage percentile ever higher. By taking a step back and looking at the design on a broader scale, it's possible to pick out the key areas of code that act as input/output junctures, and focus the tests on those areas.
Programming --- Computer architecture. Operating systems --- Computer. Automation --- computers --- computerbesturingssystemen --- programmeren (informatica) --- programmeertalen --- software engineering
Choose an application
Listing 1 - 10 of 15 | << page >> |
Sort by
|