Welcome Guest, Not a member yet? Register   Sign In
Test-driven development
#1

Test-driven development are good or bad ?
Do you use it ? What do you think about them ?

I saw this: https://youtu.be/asLUTiJJqdE and got me thinking about TDD.
Until now I didn't wrote any testing. I had the philosophy move fast and break things.

A user on other topic said somthing about http://codeception.com/ and the exemple on there site looks pretty good.

What are the best practice for testing web applications ?
Reply
#2

(This post was last modified: 04-08-2015, 02:35 AM by ivantcholakov. Edit Reason: 4 )

I can propose some random thoughts:

1. If you ship, you will win; if you write tests too much, you will loose. "Ship the f...... thing!" - http://www.joelonsoftware.com/items/2009/09/23.html
2. Write code in such manner that allows you to make a release at arbitrary moment. Code always should work.
3. "Automated testing is only about 30-40% effective at finding defects" - http://blog.ircmaxell.com/2014/12/being-...loper.html It is more important in preventing degradation and TDD.

I thing, code quality depends on you, there is no a magic methodology to eliminate the subjective factor and there never will be. If you need to test some functionality, fine, but "100% coverage" is not justified economically.

Edit:
4. If it is possible, the author of the tested code != the author of the corresponding tests.
Reply
#3

As my personal opinion test development code is good
Reply
#4

First off - Codeception is awesome.

TDD? I'm not a fan. Most of the time. I do believe that testing is a good thing and the longer I work on larger projects as the primary developer, the more I end up writing tests. Here's how I have a tendency to use tests:

1. If I'm working on a piece of code with some pretty complex logic I'll start off with tests in a semi-TDD fashion to ensure that the logic stays clean and that my refactoring while I build it won't kill anything. That also allows me to feel safer when I come back later and have to change things about this logic at the client's request. Because we all know that happens too often. Smile

2. Most of the time the code is simple enough, or I'm familiar enough with the solution that I don't test as I go. Instead, I'll go the normal "cowboy" route and get it to shipping, testing through the UI manually to test the pieces and ensure the logic is working correctly. Then, when me or the client finds a bug during QA, I'll write a test for that as I fix it. The logic here is that I missed it the first time around, so it would be easy to miss later and I can be sure that I don't miss it again. Though, depending on how narrow you write the test around that flaw, it's easy to miss other aspects of the same problem.

Other times I will go on a test writing spree:

- The client has requested a change that is central to the logic of the application. If I don't have semi-decent test coverage I'll take a few hours and beef up the tests here before I go through and start making massive changes to it. This way I know the end result is still the same even if how I got there is different.

- I'm writing a library that does something very narrow, but has a number of permutations, like a library to format UK phone numbers - I'll write tests to quickly cover the allowed possible outcomes, and a few to ensure bad ones don't get through.

So - tests, good. TDD - not my thing. It breaks up the mental image of the application that you hold as you're constructing new pieces and makes it harder to maintain overall concepts.

Disclaimer - I work primary as a sole developer. Team-based workflows where you're handed detailed specs, etc, may benefit from better testing.
Reply
#5

TDD in general is a good practice but, You could try to write a test for every possibly conceived piece of input and output and still miss something.
Writing your objects (1 or more classes) in a way that it assumes nothing (and therefore can be easily mocked) is also good practice (Dependency Injection).
Then trying to get code coverage for a small team (1 or 2 developers at 50%) is usually a pretty good starting point.
If you have a large team or are only writing a single object (like a Composer package) then having higher code coverage is a little easier.
I look at it like a insurance policy:
How much is enough? Do you buy the biggest and best and most expensive which covers everything or do you buy "just enough"?
If you want to keep your testing at 100% code coverage expect to "spend" a lot of time just writing tests and supporting files (mocks, setup, teardown, build files).
Sometimes teams go so far as to write the tests first and then the code. Large teams / budgets might have the time for that but a small team / budget?

DMyers
Reply
#6

I found this old topic.

My random thoughts.

TDD is not testing. It is about designing and development.
It does not guarantee no bugs, but it changes how you write code.

If you do TDD, you always get 100% code coverage logically.
But you can't do TDD all the time, probably because you don't have enough skill.
Of course there are areas where writing tests is difficult,
but server-side logic is usually not a problem.

It is just a skill, but very difficult to master. I don't say I can do TDD all the time.
If you need much more time when you write test code, maybe your skill is just very low.
Your poor design skill and/or poor test code writing skill make it difficult to write test code.
Also, existing badly designed code may make it difficult to write tests.

Imagine a person who cannot ride a bicycle. Which would be faster, with or without a bicycle?
TDD is like that bicycle. If used well, it can improve your code.

TDD does not make you write code faster, but if you can TDD well,
your code will be good code that is more readable, less buggy, and easier to change.
Total development time will be reduced.
To do this, you need to practice TDD, and it takes time.

The true question is how well you can do TDD.
You can decide when to actually do TDD yourself.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB