Was in a meeting today with a team I just joined, I asked what they used to write tests.. they said they don't write tests because no one would see them..

This is crazy right?

I mean, I don't write tests _just_ to get a good coverage score and brag about it on github..

I do it because nothing would ever work for more than 2 commits if I didn't.

@brod Exactly! Only if you know the scope of your project will never go beyond a certain complexity, you can get away with zero tests.

But fixing bugs by writing a test which proves the bug exists, and then fixing your code until the test goes green, is a very satisfying way of improving your project.

I don't write test because I never learnt how to do it, and I don't even know where to start to have meaningful tests.

I could easily install a lib and start doing it, but what's the point if the actual tests are meaningless?

I guess at some point I'll have to recruit someone with that knowledge, or give myself a good kick in the butt to get started already.

@Fradow my only advice is to read other people's tests, I never found a good how to / write up / tutorial on it but reading other people's work gave me a much better idea

Yep. That is trumpy crazy. Run my friend! Been there, had that, they are unprofessional. Let them boil in their own sauce. Hope u are still in probation.

Also, you guys should check out Uncle Bob's (Robert C. Martin) stuff. He writes extensively about testing and clean code in general.

@Fradow Some purists will hate me for it, but start with functional tests.

If your product is a website, your first test could be "if I visit /, do I get a 200 response code". Most web frameworks come with much more advanced tooling, to check "if a user with these permissions clicks this button, will it update an item in the database".

If you ever think: let me quickly check if that corner of my program / site still works... It should be automated using a functional test.

Functional tests are the most meaningful quick wins, but they also tend to be heavy, especially if you include everything from request to database interactions — so in many cases you start mocking: Basically saying "I trust that part of my infrastructure enough to assume it will always respond in a certain way"

Unit tests is where it gets neat. They're usually extremely fast, because they test just one method, and trust that everything around it works according to plan — you don't test more than needed.

@Fradow The cool thing is that eventually you get to a point where you can develop a website without using a browser, because you wrote tests which check if you reached the desired result BEFORE writing any actual code.

Those tests fail because the feature doesn't exist yet, and once they turn green you know your feature is ready for deployment. Of course, in practice, you still check the end result manually...

@bittersweet Thanks for the reply!

I actually did that once because we had external developers who would so often break the API they were developping that I wrote a program to test it.

After we stopped working with them, maintaining that became a burden (I was not using a proper testing library), and I stopped doing it altogether.

I'll have to pick it up again, this time with proper tooling!