Reddit reviews Test Driven Development: By Example
We found 33 Reddit comments about Test Driven Development: By Example. Here are the top ones, ranked by their Reddit score.
Reddit reviews Test Driven Development: By ExampleWe found 33 Reddit comments about Test Driven Development: By Example. Here are the top ones, ranked by their Reddit score.
Much of this stuff is learnable outside of work, too, at least at a superficially-passable level. Trust me.
Pick up a few seminal books and read them with vigor. That's all you need to do.
Here are some books I can personally recommend from my library:
Software Design
​
Software Industry
/u/nickjohnson has it summed up in this comment:
> Does NOBODY write unit tests?
A unit test is not a complicated thing. It takes one small, self-contained piece of code, sets up some situational context, runs the code with parameters set to interesting values, and then checks that certain conditions are met. (Conditions include things like: the correct result is returned, certain messages are sent, certain messages are not sent, the result is returned in less than X seconds, or whatever.)
It is important to note that while unit tests are not complicated, this does not mean they are not difficult to write. It is somewhere between art and science to write good unit tests, but it is possible. There is something like 20 years of work in this field, especially since the (capital A) Agile movement started. There are whole books on the subject, such as Kent Beck's effortlessly enlightening Test Driven Development: By Example.
Unfortunately, the number of programmers is growing so fast, that new programmers are joining the field faster than they can encounter experienced programmers, and so they are relearning lessons that were first learnt when they were still young, or even before they were born.
This problem didn't used to matter so much, but the situation has changed. Now that people know how to create money with code, code quality is not just a matter of late-night bug-fixing to get a small app released on time, it could potentially make or lose the entire net worth of a person, or even millions of people.
This is exactly the reason I've never bought a single ETH token. When I saw Etheruem, I said exactly this: "It seems to combine the properties of Bitcoin and OpenTransactions in the riskiest possible way". Some time later, The DAO showed the potential downside of that risk.
This kind of problem will not be fixed by developers learning how to write unit tests, it needs a bigger picture than that. But we will be able to put a lot of the world's wealth to much better use, if the developers of cryptocurrencies are able to find and reuse the learnings of software developers in other fields. And as Nick suggested, writing unit tests would be a good start.
https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
Basicly TDD won't help if you don't think enough about how objects are interacting. Your tests are like client code for objects you are designing. They forces you to make more easy-to-use interfaces and think more about decomposition.
>What are some good guides/practices to unit testing?
Test Driven Development: By Example is a good book to get started with
>Say I have an app with dozens of functions, how do I choose which functions to write tests for, and are there preferred style guides for these tests?
Ideally, you would test them all and you would want to write unit tests and integration tests for them.
>If it helps I want to begin by testing the front end code, whether it's generated with a framework like React or more bespoke using template strings. How do you conduct "recon" on your code to pick the targets to write tests for first, and how do you choose your testing framework?
I've never used bespoke so I can't comment on it but for React I'd recommend jestand enzyme. Jest is a testing framework that was created by Facebook (the creators of React). It's not specifically designed for React but it works great with it. Enzyme is a library made by Airbnb specifically for testing React components. Enzyme is designed to work along side Jest.
>I know you need as much coverage as possible but since you gotta start somewhere, how do you pick the starting point in your code?
The most critical part of your application
Here are some:
http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530
They are older books, but really changed my way of programming. Refactoring by Fowler and Test Driven Development by Beck.
https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672
https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
Feeling overwhelmed and confused can always be solved by breaking things into small enough problems and making enough tests to make sure that your assumptions match reality.
Frameworks can be confusing the way they hide details away from you. Remember though, that with open source, there is nothing to stop you from digging into the framework methods you are calling and see how they work. If you get stuck, sometimes looking at the source will tell you more than looking at the docs. Try multiple frameworks in multiple languages. Once you think you have an idea of the different parts required, try using a template library and an ORM library and write the rest of the code you need to make a basic custom framework.
If you want to see a more direct approach to web services, take a look at Go, where frameworks are almost discouraged. http://thenewstack.io/make-a-restful-json-api-go/
I've posted this before but I'll repost it here:
Now in terms of the question that you ask in the title - this is what I recommend:
Job Interview Prep
Junior Software Engineer Reading List
Read This First
Fundementals
Understanding Professional Software Environments
Mentality
History
Mid Level Software Engineer Reading List
Read This First
Fundementals
Software Design
Software Engineering Skill Sets
Databases
User Experience
Mentality
History
Specialist Skills
In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.
The best possible book I can advise is "Test-Driven Development" by Kent Beck. Amazon link for reference :
http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/
It's well written and introduces one to TDD in a really cool, systematic way with real-life (or real-life inspired) examples.
We assign mentors (usually the more experienced team members, but can vary depending on project and resourcing requirements) to new guys who will help them get to grips with things like our methodologies, coding standards, etc.
If we end up with a team consisting of a lot of guys without TDD experience (rare, but my teams can vary depending on other projects/resources within my company), we'll occasionally run TDD workshops where one of my senior guys or myself will go through a fill worked example of TDD, and then point the new guys in the direction of suitable resources so they can self learn (although we support them as much as required).
In terms of resources, there are a number of books we have on our internal "recommended reading" list:
There's a lot of information on the web, but I find sometimes books are just the best source.
There's a [book] (http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530/).
It's a "classic" but I personally found it on the slow/pedantic side. See if you can borrow it from someone or find a chapter online for free before you buy it.
edit - formatting
Check out:
I have a similar story, and came from a procedural background, too.
My eureka moment came when I started to understand the importance of Test-Driven Development. Test-driven Development by Example is the book that tipped the scales for me. There are more modern and pertinent examples now, but this book is a classic.
TDD will help your programming be more declarative, which will in turn help you work with frameworks like Unity.
Happy coding!
IMO you should go beyond learning node.
Learn javascript (node is just javascript with core libraries).
Actually don't learn javascript, learn how to code.
Even more, learn how to learn.
I'm not the only one with this opinion: http://blog.codinghorror.com/please-dont-learn-to-code/
Also a side point: learn how to test. Testing (may it be unit, behaviour, …) is really important. It helps you code better, have a stronger code (less bugs, or more easily identifiables), more maintainable, and so on.
If you know the basis of code, and how to learn, not only you'll know node, but you'll potentially know php, ruby, scala, whatever.
I strongly encourage you to read:
Those books are references to a lot of developers and will teach you techniques that you'll be able to apply not only to node, but to the most of languages you'll ever encounter.
Test, test and test. Read about TDD (https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530). Learn about the tools (phpUnit, phpSpec, behat) and start using them. You will find hard testing at the beginning, like everything, but later you won't want to work in without tests.
Apart of that, learn how the composer package manager works and don't do anything without it. Don't reinvent the wheel and use components that someone already invested a lot of hours in (auth, orm, microframeworks).
Think about your systems as a composition of pieces that work well together, without need of coupling to a specific framework.
My only reservation here is that it's not really a TDD exercise. TDD typically involves choosing and writing tests for the functionality being added next by the developer, as opposed to here where the test dictates the next piece of functionality to add. It's a subtle difference, but a tangible one.
Now I'm not saying that this isn't a good idea. I'm not saying it isn't useful. Just that it's not quite TDD, as the design evolution is already in place for you, and you're just writing the code.
For a great example of what I'm talking about, check out Kent Beck's Test Driven Development, By Example. He walks through developing a few applications using TDD while keeping a "mini backlog" of what to do next, constantly adjusting the priorities.
Again, not putting this down, just not quite sure if it's as much as a TDD exercise as a testing exercise. But it's an interesting concept...
https://www.amazon.co.uk/gp/aw/d/0321146530/ref=pd_aw_sim_14_1?ie=UTF8&dpID=51EH1TQ3A2L&dpSrc=sims&preST=_AC_UL100_SR100%2C100_&refRID=RJSR3E839T12AKF87ABV
Yes, his book is titled "Test Driven Development: By Example".
http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530
Try Test-Driven Development. In TDD, programming proceeds by accumulating ever larger catalogues of concrete examples. Get hold of Beck's Test Driven Development: by example Get your buddies to set you up with a TDD environment in Ruby and off you go.
This pretty much defines the TDD workflow. It's exactly as mr_chromatic describes it.
In the interest of giving you something to do which differs from what just about everyone else will say... write the following failing unit test and make it pass ;P
import question
import unittest
class ProjectTest(unittest.TestCase):
def testGetQuestion(self):
test_obj = question.Question()
expected = 'What is the sum of all fears?'
self.assertEqual(test_obj.GetQuestion(), expected)
Refactor, rinse, repeat.
A great reference
Another great reference
Today the defacto way to design something is though tests. Some people might disagree with me here but I believe that Test Driven Development can help. You may want to do a small top level design but before you write any code you must always write the unit test for that code first. This way you can see how it is going to be used before you spend time coding it. Each of your tests should represent a piece of functionality in the code base. As you write each test you implment just enough code to get it to pass before you move on to the next one. Never regressing by letting old tests fail.
I usually start with a top level class and work out it's relationship to other objects in the design through interfaces. Then I'll write tests for each of the dependent objects and work top down like this. This is known as the London style TDD. There are other ways as well.
I reccommend this book:
Growing object orientated design through tests
Also this one, (but it's a bit long winded and it's a different style of TDD)
Test Driven - Kent Beck
If you want an excellent whirlwind tour to computer science basics with a language you've probably never heard of, I'd recommend MIT's Structure and Interpretation of Computer Programs course. The video lectures and the course book are available free online. It's pretty tough going but will seriously expand your mind :)
For design stuff I'd recommend reading books about OO testing and refactoring, like this or this.
EducacionIT es decente. Mas allá de lo que hagas. Lo mas importante es que practiques e intentes hacer cosas. Lo que lees no sirve si no lo usás.
Te recomiendo muchísimo que aprendas, en cuanto sepas usar mínima-mente las herramientas, como hacer unit tests y que es Test-Driven Development.
Este libro es excelente para entender TDD y está en java
Interesting!
Looks to me that you can "feel" what good code looks like but you're not able to rationalise it enough for you to write it on your own.
Couple of suggestions:
When you see elegant code, ask yourself: why is it elegant? Is it because is simple? Easy to understand? Try to recognise the desired attributes so you can try to reproduce on your code.
Try to write really short classes/methods that have only one responsibility. For more about this, search for Single Responsibility Principle.
How familiar are you with unit testing and TDD? It should help you a lot to write better designed code.
Some other resources:
I don't know of any one source that teaches "good testing principles". There are thousands of sources and Sturgeon's law is working against you. A few sources are predominantly good, most have bits (often the same bits) of genuinely good advice in-between chapters of bland, uninsightful repetition, many are appropriations of popular acronyms by closely or distantly related professions (no, you're not "testing" a requirement specification, you're just reviewing it), and some sources are just plain bad.
I had an opportunity to attend Dan North's Testing Faster course and would strongly recommend it. In my case it was more helpful for formalising my own experience than learning concrete new things but other attendees did absolutely "learn new things". He made a point that "TDD" and "BDD" are both inaccurate names and that something like "example-guided development" would have been far more honest; he recommended a book, I think Specification by Example, as a good resource to that end (and noted that that name, too, is technically inaccurate). He also confirmed that Cucumber is a solution looking for a problem.
Test Driven Development: By Example by Kent Beck is a classic, and as far as I can remember, decent. It's maybe a little old now, and it definitely misses some subtle points about maintainability of automated tests in general (or perhaps rather, doesn't really address that).
I've skimmed Code Complete 2. I don't remember it in detail but my overall impression of it was that the sooner it becomes irrelevant the better, because that would signify our profession maturing (if not quite reaching maturity). A lot of its contents would be considered basic by contemporary software development standards and that's a good thing. I don't remember what it says about testing. One thing in a very late chapter (33.8?) stuck with me, though: that seniority has little to do with age and your approach to software development will be formed early on.
Working Effectively with Legacy Code by Michael Feathers is excellent, perhaps the most practically applicable one here.
Sandi Metz is famous in the Ruby community for speaking on this topic and there are recordings on YouTube. From what I've seen her material also mainly addresses beginners but it's fast and easy to consume and her form doesn't bother me the way Martin's does.
One piece of advice I picked up from one of those mostly-mediocre sources had to do with naming in tests, trying to capture the essentials. If you're relying on a particular property of a piece of input to test behaviour, make sure this is evident. Conversely, if any input would satisfy, avoid drawing undue attention:
fn bees_can_fly() {
let some_bee = ...
let bumblebee = ...
let dest = ...
assert fly(some_bee, dest);
assert fly(bumblebee, dest);
}
fn bees_can_pollinate() {
let some_bee = ...
let flower = ...
assert pollinate(some_bee, flower);
}
Testing is about developing confidence. There are many kinds of testing and many things to develop confidence in. For automatic tests it's more about checking (arguably not "testing") that you retain correctness in the face of continuous change. Automatic tests that obstruct that change or compromise your confidence are not helping you and should be rewritten or removed. Reliability of tests is usually more valuable than coverage, for instance.
Read the PHP manual, a couple times - http://us.php.net/manual/en/index.php
The two books that did the most for my coding are:
Refactoring by Martin Fowler:
http://books.google.com/books?id=1MsETFPD3I0C&lpg=PP1&dq=refactoring&pg=PP1#v=onepage&q&f=false
Test Driven Development: by Example by Kent Beck
http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
You should definitely learn other WebDev techniques .. ASP.NET/Java to embrace the order, Ruby/Python to embrace the chaos.
Point? You write enough test code to make it fail, you then write enough feature code to make it pass...
For more information http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530
I would offer the following:
All the books are in fantastic shape, from a non-smoking house, owned by a man who treats books like fine china (me).
The problem is, I live in Romania, so the postage fees will probably make the exchange not worth it (I never made an exchange this way before and I have no idea how much would the shipping cost).
This guide will get you started with testing in Swift 4. It'll help you get everything set up properly and show you how to write your first tests in Swift. If you want even more depth, you could try Test-Driven iOS Development with Swift 4, Test-Driven iOS Development (Objective-C), or the seminal book, Test-Driven Development: By Example which uses Java.
You gotta read Test Driven Development
You need this: http://en.wikipedia.org/wiki/Software_design_pattern
More specifically you need to develop good understanding not only of what design patterns are but also...
These things can take a long time to get used to. Object Oriented is a very useful paradigm to work in but it is, in itself, a design pattern. It is also useful to know when you are better off not doing things in an object oriented way.
But probably the most important bit of advice, and the thing that helped me to properly understand OOP is unit testing, and how to do it properly. If you haven't yet read it, then read this book and apply what it teaches you in your projects. Learn to use a good testing framework and a good mocking framework (in c#, for example, my preference is for Moq and NUnit) and learn to express yourself in test code. Learn also about dependency injection. These testing techniques, and the TDD story, will guide you not only in writing the units of your project, but also in architecting it and letting testability guide the design. Once you see how the design of your code is affected, you'll start to understand OOP a lot more, and also the finer points of the design patterns you want to implement.
Good luck :)