Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
What book would you recommend to learn test driven development? Preferrably language agnostic.
Test Driven Development By Example
Refactoring: Improving the Design of Existing Code
Extreme Programming: Embrace The Change
Growing Object-Oriented Software, Guided by Tests by Addison-Wesley - it is about mocking frameworks - JMock and Hamcrest in particular.
From description of the book:
Steve Freeman and Nat Pryce describe
the processes they use, the design
principles they strive to achieve, and
some of the tools that help them get
the job done. Through an extended
worked example, you’ll learn how TDD
works at multiple levels, using tests
to drive the features and the
object-oriented structure of the code,
and using Mock Objects to discover and
then describe relationships between
objects. Along the way, the book
systematically addresses challenges
that development teams encounter with
TDD--from integrating TDD into your
processes to testing your most
difficult features.
EDIT:
I'm now reading Working Effectively with Legacy Code by Michael Feathers which is pretty good. From the description of the book:
Understanding the mechanics of software change: adding features,
fixing bugs, improving design, optimizing performance
Getting legacy code into a test harness
Writing tests that protect you against introducing new problems
This book also includes a catalog of twenty-four dependency-breaking
techniques that help you work with
program elements in isolation and make
safer changes.
I read it already, it is one of the best programming books I've ever read (I personally think that it must be called Refactoring to Testability - it describes the processes for making your code testable). Because a testable code is good code.
For me, this is the best one:
Test Driven Development: By Example by Kent Beck
Fairly recent reasonably written book The Art of Unit Testing. I am surprised it wasn't mentioned here.
The Astels book is a solid introduction, Beck's book is good on the underlying concepts, Lasse Koskela has a newish one (Test Driven: TDD and Acceptance TDD for Java Developers). Osherove's book, as he says, is about Unit Testing, rather than TDD. I'm not sure that the Pragmatics' TDD book has aged as well as their original book.
Most everything is Java or C#, but you should be able to figure it out yourself.
I'm a big fan of almost anything from the Pragmatic Bookshelf, but these two really helped drive the point home for me:
The Pragmatic Programmer: From Journeyman to Master. This ages really well. I'd recommend it to any developer.
Pragmatic Unit Testing in C# with NUnit, 2nd Edition. Don't let the title scare you. The concepts are pretty language agnostic, even with the C# examples.
Dave Astels' Test-Driven Development: A Practical Guide
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What are all the advantages of BDD(Behaviour Driven development) framework and cucumber?
I want to know what are all the advantages of BDD.
I totally agree the communication is one of the biggest advantage however the benefits are for all the parties involved and the advantages for those are different.
So briefly:
For All:
living documentation
collaboration, early discovery of unknowns
enforce building domain vocabulary and semi formal language (DSL) to
express system behaviour consistently within the organization
For devs:
like TDD, it helps to think in chunks, create nice and testable code.
write code for what is needed only (build the right thing)
better coordination between different dev teams developing similar
features with different technologies
For QA:
ready acceptance criteria
ready building blocks for all kind of tests
test what is exactly need (test the right thing)
For PO:
think and reason features in detail thus produce better specs
better visual and coordination with other Managers and Product owners
better visual and understanding on Devs and QAs output/report due to the same source/format of
specs
in my opinion, the biggest advantage of BDD is the increase of communication when you introduce it in the way it was meant.
An excellent article about this is from Richard Bradshaw - have a look at
Using BDD Tools To Write Automated Checks != BDD
The idea is that the three amigos (QA, Dev, and Business) collaborate to create the feature files. That leads as mentioned to a lot of communication before a story goes into production.
Another advantage (but surely not the main one) is that the test cases are human readable - and if you have to create reports for non-technical folks, you have it a bit easier.
But on the way of implementation, which I've often see, where the Testers have to create the features and implement the Tests by themselves is a huge overhead and is also an antipattern in BDD.
I hope that helped a bit!
Agreeing with Thywen, these are things BDD brings you:
Better communication
Examples are easy to understand, discuss and criticize
Easier to find things you didn't know you didn't know.
Building the right thing
Automated acceptance tests
The examples are executable
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I want to ask you to provide me with some articles (maybe books), which you possibly have found very convincing criticising the OOP methodology.
I have read some in the WWW on this topic and I didn't really find a 'definitive demotivator'.
It's not much about my personal attitude to the OOP, but I really would like to have something constructive, rigorous foundation for any kind of discussion and just abstract thinking.
You can post some original research too, but please be very constructive (as my personal request).
Which version of OOP? Alan Kay's original vision? The bastardized modern form of it that misses the point entirely and thus encumbers us with bizarre access control, member variables, etc? Inheritance-centric? Prototype-based? Compositional OOP?
Each form of OOP has its strengths and its weaknesses; its advocates and its detractors; its domains of utility and its domains of uselessness. There's nothing magical about OOP that makes it the Killer Paradigm and there's nothing infernal about it that makes it the Killer (of Programmers) Paradigm.
I can't really point you to any books or articles that killed my interest in OOP as a Silver Bullet (as opposed to one of many techniques I can use to keep my projects survivable). I can point to the funniest critique of a specific brand of OOP, however: Steve Yegge's classic "Execution in the Kingdom of Nouns".
Rick Hickey's Are We There Yet ? - A Deconstruction of Object Oriented Time was an eye opener for me. It's the most logical OO criticism I have come across.
If you want a criticism of OO programming, here's what I'd recommend:
Learn Smalltalk
Learn Erlang
Learn Scheme
Once you've done that, you will have plenty of criticism of the common interpretation of OO programming.
(Hint: OO was in many ways intended to more closely resemble the Actor model of computation, but the common interpretation of it is effectively a modification of the procedural/structured model)
Problem is - most people don't really know Object-Oriented Programming, so many designs SUCK.
Read the works of Scott Ambler, including his (now pretty old) Building Object Applications That Work. This has been eye-opening for quite a lot of people.
Maybe not quite what you were looking for but have a look at the Jan/Feb issue of IEEE Software magazine: Object-Oriented Analysis: Is It Just Theory?. The basic conclusion is that OOA does not provide a good cost/benefit ratio so is poorly utilized.
Given that OOA is not effectively utililzed or supported in the "real world", I suspect that for larger development projects the overall system architecture, deployed object model and class hiearchy end up being sub-optimal and poorly understood (implemented) by various parts of the development team. A second article in the same journal: Four Trends Leading to Java Runtime Bloat point to some common OOP issues that detract from deploying high-volume Java (OOP) systems. The observations made in this article probably apply to most highly architected OOP applications.
Do not take this as OO bashing, it just reflects that as software practictioners we have quite a bit of work to do toward developing better person-to-person communication mechanisms to convey highly complex and abstracted process models.
When you define a process in natural language. You use sentences where you define the subject who will do an action on one or more objects.
The only fix point is the action, the predicate of the sentence.
I don't think assigning actions to objects is a good idea.
There is only one verb, but can be multiple nouns.
In OOP you can write a file in at least 3 ways:
file.write(data);
or
data.writeToFile(file);
or
OperatingSystem.write(file, data);
Which object should implement the method? You need to think about this too.
While in the procedural way, you probably write
write(file, data);
And the only thing you need to think is the order of the operands which is usally does not matter.
(Well file and data may not be the best example but you probably see the point)
You should really see Mr. B. Jacobs's:
OOP Myths Debunked
(also known as OOP Oversold.)
http://cat-v.org has a great page on Object Oriented Programming.
Most of the page consists of humorous but not terribly informative quotes. However, at the bottom of the page are a number of links to articles challenging OOP. They are:
Bad Engineering Properties of Object-Oriented Languages by Luca Cardelli.
Why OO Sucks by Joe Armstrong
Pitfalls of Object Oriented Programming – By Tony Albrecht of Sony Computer Entertainment Europe, Research & Development Division.
Object-Oriented Considered Harmful by Frans Faase.
Object Oriented Programming Oversold!
I Hate Patterns – By Parand Tony Darugar.
Why arc Isn’t Particularly Object-Oriented – By Paul Graham.
The questions about inheritance in the Java IAQ.
Stop Writing Classes – Great talk about how classes are often used and abused. By Jack Diederich.
If you are interested in alternatives to Object-Oriented Programming:
cat-v.org. From their 'about' page: Cat-v.org hosts a series of sites dedicated to diverse subjects that share an idiosyncratic intellectual perspective, questioning orthodoxy and fomenting elitism and high standards in topics from software design to politics, passing by art and journalism and anything else interesting.
Structure and Interpretation of Computer Programs. Specifically teaches functional programming. Available free online here, for sale here. I cannot recommend this highly enough. It is absolutely revolutionary. It will change the way you think.
Any and all writings/videos/lectures by Rob Pike and Steve Yegge. Of particular interest is Yegge's Whirlwind Languages Tour.
I'd recommend learning a different programming paradigm or reading pro arguments for specific paradigms (http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf). Besides OOP, I think the most widely used is the functional paradigm (search f.e. "Why functional programming matters"), but also have a look at the other ones. When you start looking at programming from a different perspective, the flaws of OOP start to appear automatically.
Simple exercise: define the objects IPerson, CMale and CFemale and implement the methods "sex" and "reproduce".
hows about steve yegge's execution in the kingdom of the noun
for java style OO
The Gideon Bible of object-oriented design patterns, aptly named Design Patterns. One of the best software design books I've ever read.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am about to go for an interview for a software testing summer job. What questions should I ask the professor about this + I have never done software testing before, any good reference material you can recommend will be appreciated.
thanks
You should be prepared to discuss a variety of testing terms, such as:
"black box" testing, "white box" testing, etc.
unit tests
functional tests
smoke tests
BVTs (Build Verification Tests)
the differences between stress testing and load testing
performance testing
globalization testing
interoperability testing
manual testing vs. automated testing (when?, why?)
api testing
security testing
regression testing
code coverage testing
(etc...)
You likely don't need experience in all of them, but you should express an awareness.
A general knowledge of the following is helpful (refer to IEEE 829 for a start):
- test plans - what should be in a good plan?
- test cases - what should be in a good test case?
- test design specifications
- incident reporting (including bug tracking)
- software specifications - what does one look for?
You should start thinking about how you would test different things. What are the base cases? Are there any boundary cases? What could be wrong with any given product or item? Think creatively...
For a few starting references on testing, I suggest looking at the following:
Cem Kamer's book on software testing
Wikipedia for some more starting points
IEEE 829 (related articles should be sufficient to get you thinking, as the full spec is good for insomniacs)
If you've never done software testing before, it would be a good idea to learn some things quickly.
I'd recommend checking out the Black Box Software Testing course, available free (without an instructor) at http://www.testingeducation.org/BBST, or in an instructor-led version that is free to members of the Association for Software Testing (http://www.associationforsoftwaretesting.org). This is a university-level course, hours and hours of video, supplementary materials, quizzes, self-tests, and pointers to other information.
James Bach and I co-author and teach a course called Rapid Software Testing (http://www.developsense.com/courses.html). The course notes for that are available for free at James' Web site, http://www.satisfice.com/rst.pdf.
I've written a lot of articles on testing for Better Software magazine. They're available free at http://www.developsense.com/publications.html.
In addition, there's a blog post for you: http://www.developsense.com/2009/02/how-can-trainee-improve-his-her-skills.html
There are several testing communities online where you can ask questions and get mentorship. http://www.softwaretestingclub.com and http://www.testrepublic.com are two of them.
Best of luck.
---Michael B.
Besides the questions you will be asked, don't forget the interview is actually a conversation. And you look much better if you ask questions yourself. So, let me say few things I'd ask if I were you :)
For me, when it comes to working as a tester, most important is communication. How well you can communicate with team members, managers, team that develops the software you test.
Do they use some kind of bug tracking system, if so, what system is it? Is it the same system the development team uses?
Does this tool cover most of communication needs, or there gonna be a lot of calls / email exchanging resulting in a total mess in discussions about issues?
Is there any automated tool used for testing? This gets you quite close to what are your responsibilities on this position, so will probably be covered in the interview anyway.
Do you get 2 monitors ;) ? (Really, getting a second display was like a huge improvement for me in tester job). Do you get the tools that make your work faster and more effective?
Terms, definitions and tools are important thing... but analytical skills, logic, communication and other skills may be more important.
Maybe It won't be a summer job, but a career.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I find that whenever I begin writing an app in Java/C#, things start off good, but over time, as the app becomes more complex, it just gets more and more complicated. I've become aware of the fact that I'm not very good at design and high level architecture. All my classes become fairly strongly coupled and the design isn't "elegant" at all. I'm fairly competent at "low level" programming. That is, I can get just about anything done within a function or a class, but my high level design is weak and I'd really like to improve it. Does anyone have pointers to techniques, books, etc. that would be helpful in making me a better software engineer?
I disagree about starting with a book on design patterns or refactoring.
In my opinion, for a solid OO design, you should first be familiar with the main OO design principles, then understand how your problem can be represented in those basic principles. Then you can start discovering opportunities for applying design patterns and refactoring techniques in order to achieve those fundamental principles.
I would start with this book:
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
In this book, Robert Martin describes the fundamental principles that make a good OO design, all of them related to encapsulation, coupling and modularity:
The Open/Closed Principle
Liskov Substitution
Dependency Inversion
Granularity
Common Closure
Reuse
No Cyclic Dependency
Stability Of Dependency
Abstraction And Stability
After all, almost every Design Pattern and Refactoring technique I have seen documented in GoF and Fowler is aimed at achieving one of several of these basic principles, depending on their relative priority for a given scenario.
Books:
Code Complete, by Steve McConnel
Design Patterns, by Gamma, et. al.
I would start by sketching my design. That sketch could be a box and arrow diagram to show relationships between classes or it could be a variation on UML (or perhaps even standard UML). But I find that sketches help me see that a design is good/bad and maybe even how to fix it.
I would also look at a book on design patterns.
Write a large project and let it spread as big as you can. Then study what you can do to improve your code.
Perhaps single large routines can be clean and understandable too, if they are well-structured.
There's no single good answer on good design. It's actually one of those valuable things a programmer can learn.
You can refactor mercilessly to improve the design of existing code.
The main idea is, at some point the code did make sense, when new features are bring into the code then probably some features or responsibilities must be moved around to another classes, that's fine. Then you stop developing new features and start refacoring your code.
I would recommend you to read:
Refactoring by Martin Fowler
use Object Oriented Design Principles (http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm). also consider some oo design heursitics (http://www.cs.colorado.edu/~kena/classes/6448/s02/lectures/lecture27.pdf)
Try making program outlines and diagrams before you start, and have someone else review and critique it. Then as the program grows, continually update the outlines and diagrams to include the new functionality. Get it reviewed and critiqued by someone else. Eventually, assuming you are learning from the critiques, you will become better at designing programs.
Books and tutorials can only get you so far. While you do need to learn the tools and methods available, knowledge on its own won't help you here. Practice is what will make you better at design, along with having a mentor coach you from time to time to show you how you can better apply some of the knowledge you've gained from the books.
Read the books by all means, but don't feel bad if you write code that ends up having stupidities in it. Everybody does. The question is, can you refactor what you have to fix it? To be able to do that effectively and often, you need to use TDD and write lots of unit tests.
I would highly recommend you try Test Driven Development (TDD). You will find that to make your code testable, and not need to constantly perform rework of your tests, you will need to have a solid design. What you will find is that when you add \ change \ remove functionality, your better designs will require a very small set of changes to a specific set of tests. A poor design will wipe out a huge set of tests - because you have tight coupling, objects responsible for multiple concerns, etc, etc, etc ...
I have found that the better I get at TDD, the better my architecture is, and the better the end result is.
Be advised, TDD takes real mental discipline. You should not expect that you use it for 1-2 days and see immediate results. You will need to really want to do it, and really make the effort - otherwise you won't benefit and likely just end up hating it.
HTH ...
There are a couple of things that you can do
Use tools for high-level and
low level design before you
actually start programming. E.g.
Creating Class UML Diagrams will
help your mind visualize the
solution in a Diagramtic form rather
than Code form.
Familiarize yourself with Java
Design Patterns. E.g. Using
Inheritance Polymorphically to begin
with will warm you up to start using
the standard Java and J2EE design
patterns.
There are a tonne of books and websites pertaining to both the subjects I just pointed out here.
Browse through good API code. For instance Spring framework code.
Read some good books such as Design Patterns (like everyone else mentioned here) and some other books on good practices. For example in Java, Head First Design, Effective Java series, etc.
C++ - Effective C++ series
I would start with : Head first object-oriented analysis and design. and once you mastered it : Head first design patterns.
Obviously, reading some of the recommmended books will help. I think Head First Design Patterns is definitely less abstract than GoF book.
The primary question I ask is "Is this code doing something very specific that could be re-used anywhwere else?" If so, put in in a class in an assembly that allows for re-use.
If you truly are just starting then one thing I used to do was to consider each database table an 'object'. So each database table represents a class. The purists will tell you this is a disaster, but I found it a good way to get myself started thinking in object terms.
Read Head First Design Patterns.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
What is a good challenge to improve your skills in object oriented programming?
The idea behind this poll is to provide an idea of which exercises are useful for learning OOP.
The challenge should be as language agnostic as possible, requiring either little or no use of specific libraries, or only the most common of libraries. Try to include only one challenge per answer, so that a vote will correspond to the merits of that challenge alone. Would also be nice if a level of skill required was indicated, and also the rationale behind why it is a useful exercise.
Solutions to the challenges could then be posted as answers to a "How to..." question and linked to from here.
For example:
Challenge - implement a last-in-first-out stack
Skill level - beginner
Rationale - gives experience of how to reference objects
Building Skills in Object-Oriented Design is a free book that might be of use.
The description is as follows:
"The intent of this book is to help the beginning designer by giving them a sequence of interesting and moderately complex exercises in OO design. This book can also help managers develop a level of comfort with the process of OO software development. The applications we will build are a step above trivial, and will require some careful thought and design. Further, because the applications are largely recreational in nature, they are interesting and engaging. This book allows the reader to explore the processes and artifacts of OO design before project deadlines make good design seem impossible."
Write a challenging program from scratch. Try to get some people (around five, that should be doable) to use it. Respond to their change requests.
Adapt your program's design. Start small, then watch it grow. Manage this growth. This is hard. You will also have to fix bugs and maintain the thing over time, which for me was a very valuable lesson.
Challenge: Write a wrapper for your web site/service API of choice in your language of choice, that doesn't already exist (ex. a ZenDesk API wrapper written in C#). Release the wrapper as open source for others to use.
Skill Level: Beginner to Intermediate
Rationale: To learn how to extrapolate a 3rd party web service API into a meaningful set of objects/classes, making the reuse of that API easier in your chosen language.
After you have learned the basics, study the "Gang of four" design patterns book.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1221488916&sr=8-1
This is a classic, and a must read for any coder who wants to understand how to use OO to design elegant solutions to common coding problems.
Take a procedural-style written piece of code and try to transform it into OOP based solution. During the process, consult a book on refactoring and design patterns. A friend of mine was able to make a huge step forward in understanding object oriented concepts exactly this way. As with anything, this might not work for everyone.
I have found CRC cards to be quite effective in learning, teaching and building good OO design.
Certainly a good challenge, although less accessible than a "start from scratch" assignment, is to refactor some existing code that either doesn't use inheritance or doesn't use very much of it to make greater use of inheritance. The process of refactoring will expose a lot of the benefits and gotchas of oop, as it certainly has for me on my most recent project. It also pushed me to understand the concepts better than past projects have where I've created my own object oriented designs.
A given task has very little to do with being "OOP", it's more in how you grade it.
I would look at the Refactoring book, chapter 3, and make sure none of the bad code smells exist in the solution. Or, more importantly, go over ones that do apply.
Most importantly, watch for the existence of setters and getters (indicating that you are operating on values from a class and not asking the class to operate on it's own values)--or using "extends" without applying the Liskov Substitution Principle, stuff like that.