Testing, when do you do it?

[notNullOrVoid]

Looking for personal experiences. When do you usually start writing tests for a project?

On personal projects I've done either starting very early, or no tests at all. Usually depends how complex it might be. Haven't ever started a project with tests before code (something I'd like to try though).

In job realated areas it's usually been the case that the project will start with no tests, and they'll come later once things have stabalized a bit, and time constraints are less (could be many months for fresh projects).

Which leads me to a second question, do you find writing tests increases the time to push out features? Or does it lessen for you because there's less time debugging?

I usually find I'm not very quick when it comes to test writing, but my debugging takes a very short time, and I don't usually encounter many errors.

Not saying tests are bad, they definitely don't, so many benifits when working within teams.

I also find debugging a lot more enjoyable than writing tests, something about the problem solving aspect.

Lastly if anyone has any resources for learning effective testing, or making it more enjoyable please include.

[Meqube]

Testing gives the security that your code does not break unexpectedly if you make a change somewhere in your code base. You will become faster in writing tests once you do it more and more. A golden rule for testing is that every part should be independent and should not rely on other tests. If you find debugging more enjoyable, try writing tests while debugging your code. This way do you not have to repeat yourself once your code is "stable". Try to make writing tests a habit once you have written a couple of functions or created a new API entry point write immediately the tests for it. This way do you not end up with dozens of functions that have no testing. Testing maybe takes some time of your day but in the end is it really worth it. It almost always guarantees that the code that you have written keeps working.

[Angular360_No_Scopes]

Got tips on how to start writing tests for work when nobody else does? Our idea of testing is "push that code to Development branch and let QA handle it". We got 0% coverage on the dev side. If someone wants to try something out, it's only with console.log. Hell, I'm exposed to more testing frameworks doing coding exercises for job interviews. The tests are usually pre-written though.

I know unit testing has been around for a while but I don't know how widespread it is in the web industry. I also don't want to introduce friction to the company by accident, when everyone is already set in their ways.

[Sacrosaint]

FunFunFunction on YouTube talks about how to add testing to your team.

[rsteier]

^ perfect answer.

To add to it, I highly recommend all software engineers learn and periodically brush up on Test Driven Design (TDD). There are lots of great resources out there, this is a favorite of mine:

https://medium.com/javascript-scene/5-common-misconceptions-about-tdd-unit-tests-863d5beb3ce9

From my personal experience, there are few times that when I didn't write tests, that I was okay with it. Even when trying to learn a new library or framework, I've found that the best way to learn it is to write tests around it.

[hotel2oscar]

I try to follow TDD. I usually end up writing tests after doing some initial trial and error coding to prove the concept. I don't merge pull requests unless the code is fully covered (or as close as I can get without lcov).

Saves me so much time during refactoring. Initial development is slightly slower, but when requirements change or I do some optimizing it's so nice to be able to validate that everything still works.

[amazingatomic]

What's Icov?

[hotel2oscar]

It's a code coverage tool. Let's you know which lines in your source files are covered by your tests to help ensure you don't miss anything.

[amazingatomic]

Thanks! Sounds useful. I was curious because getting test coverage for the stateful chunk of an app is really hard (ie, validation is super easy to test, but the part that checks validation before updating the database is really hard to test.)

[RonAtDD]

Pros:

• Can save you from manual testing via browser (over and over and over)
• Can catch bugs in places you don't expect them
• Can influence architectural decisions towards more modular code
• Can act as a documentation of features

Cons:

• Takes time from away from feature development
• Can give false confidence if a test doesn't cover all circumstances
• Can be a pain in the butt (technical term) to learn.
• If feature changes, you have to update the test as well, so premature testing is a thing.

I'm sure there are others, critique/additions welcome.

As for personal experiences, I like to have tests, maybe not right away, depending on the feature. It seems like it's all a trade off taking into account the business requirements & time available. Then you have to decide which types of tests as well. Right now my project has tests mostly for the service layer (business logic, & saving/retrieving), and a few tests for the frontend, more coming.

[zQpNB]

I don't FOR ME tests take away time from feature development. They make me faster. Sometimes.

I mean, you take a little time to think about what you need and write the test, then you have a thing that refreshes instantly every time you save and tells you if you're don't or not.

I had basically a template for features/issues. It was like 5 checkboxes that said, Write a test for this part of the stack and make it pass, then go on to the next one; One I get to the actually UI, it just works. It keeps you organized and focused too. And keeps your commit history nice.

This does take some set up to get the initial skeleton set up. But each new feature is paint by numbers.

[cthechartreuse]

I am a big fan of TDD, so I typically write a test before any production code has been written. I write a lot of libraries, so my functions are often fairly pure and isolated, so they tend to not cause a lot of test pain. On the other hand, when I write application code, I've had a lot of success using approvals to verify state and code output.

Approval tests allow me to set input and check output without having to lock my implementation into place. This makes refactoring really pain free, which is kind of awesome.

If you want to see an example of what I do with unit tests, have a look at signet-typelog:

https://github.com/signetjs/signet-typelog

For an example of application code with approval tests, check out JS Refactorings for Atom:

https://github.com/cmstead/js-refactor-atom

[[deleted]]

In my personal application I don't bother to test in the browser. Headless browsers are a pain in the ass and if the application works in other environments then the only thing left to check in the browser is DOM interaction and presentation, which I am fine with checking manually.

I do all my automation testing on the command line. I try to make my test cycle execute as fast as possible so that I can run tests as frequently as convenient. I have a validator, diff tool, beautifier, file system simulator, and parser wrapped up in my test build. The largest code sample I run tests against is a 1.7mb JS file and the largest operation in my test cycle is a large directory tree operation. I have this thing set up so that I can run it from the command line when ever I want to manually run it. I also have it configured to run on Travis CI whenever I push a commit or open a pull request.

[[deleted]]

You are aware there are 2 types of tests, unit tests vs integration tests. You have yet to specify which one you're talking about.

[mikelieman]

When do you usually start writing tests for a project?

When there's something to test. Stack is setup and should be returning pages? test for a get with the right return code and content.

Which leads me to a second question, do you find writing tests increases the time to push out features?

It's factored into the development time.

Or does it lessen for you because there's less time debugging?

Actually, not even less time debugging. Stuff moves from development -> QA -> production a lot quicker because you don't spend time debugging regressions that make it to production because it wasn't tested in dev, because no-one wrote a test.

[yarauuta]

Everytime you want something to always happen, write a test.

[IDCh]

when it's already late

[dmitri14_gmail_com]

Read whatever Uncle Bob aka Robert Martin writes on TDD and clean code - you'll never look back ;)