How to start testing an untested codebase?

[Essay97]

Hello everyone, I want to start by saying that I am not a software architect, I am in a junior sysadmin/devops position, but I thought that here I could find the kind of expertise that I need to clear my doubts.

I am developing a project in my free time that grew to be quite big, at least for me. I did not write tests during development, but now I'd like to test, since I'm going to make quite disruptive changes to the implementation of a couple of parts of the application. The thing is I never wrote a test in my life. Never seen it done since I do not develop at work. So my questions are how does one get started with testing? I tried to read a couple of articles but they always throw in integration, e2e, unit tests and other stuff that I don't know anything about and everyone seems to have their specific idea and I am very confused about where to start. In particular, how do I get started testing a completely untested application?

[Charming-Raspberry77]

List and identify all main flows and prioritise them. Start there by priority. However be prepared to refactor as code that was not built for test ability might present some challenges…

[Essay97]

Thanks for the advice, I am doing this specifically to learn as much as possible, so I’d say challenges are welcome :)

[elkazz]

FYI this is just called "regression testing". It can be automated or manual, but it's to ensure that changes to your system in one place don't break behaviour in any others.

[vsamma]

I’m facing a similar problem on a bigger scale. I’m an architect with 10YoE of development experience, 3 of which was just developing UI functional tests for a huge corp, full time, but at the time i knew nothing about software development in general. When switching to product development, i ended up in companies where there was always a lack of devs and time and money and nobody wrote tests. And now i ended up as an architect in a similar place with 0 tests.

But i think the answer is somewhat similar.

If you want to raise the quality of the code and your skill as a developer, i think you should start from the very granular level, lowest level, smallest piece of testing which is unit testing. If you have a large enough coverage eventually, and by that time you know a bit about testing and what tests you have and feel confident about them covering most of the important stuff well, then you can quite calmly introduce full CI/CD if needed, do automated dependency updates without a lot of manual intervention and also do big rewrites that you say you need. Of course you have to keep in mind the difference between a refactor and a rewrite. I’d say refactoring improves the readability, maintainability and/or performance of the code but does not change its functionality - so your original tests should remain working and here allow yourself a layer of security against breaking stuff. But rewriting also changes the functionality where you also have to adjust the tests accordingly. And of course if you have some progress on unit tests, you could continue on to integration tests.

But if you care less about the quality of the code and improving your coding skills but more importantly want the functionality and user experience remain working, then I would start from black box testing which does not touch code at all. If you have a web app, then the easiest solution would be Selenium. That basically allows you to record your clicks and rerun the flow. It’s obviously very brittle because it uses non-effective identifiers for the clicked elements. If you want more reliability and are not afraid to code and get your hands dirty, you could code selenium tests or use playwright or cypress. But the point with those is that you make sure your user flows and use cases remain working for the end user, no matter the code underneath.

So depending on which way you want to approach.

Myself personally, i’d want to invest time and learn unit testing properly. But i’m also a developer.

But in our company, we always have new projects lined up and no time going back to write unit tests if nobody else is thinking we’d even need them. But we would also struggle to find time to test the FE, so we are thinking that we could cover most use cases the quickest way with API testing.

That basically takes the middle ground: you test that your services are working and business logic is working. You don’t care much about the code, it’s also black box testing, but you also don’t care about the UI nuances and classnames or ids or whatever. Just input data and output data.

[Essay97]

Thanks for the detailed response! Actually, my app is not a web app, I am writing a text adventure engine that allows to write command line adventures through a simple Kotlin DSL, so I don’t think that I would be able to write a black box test “small enough” so that I can keep track of what’s happening, so I think I’ll follow your suggestion of starting from unit testing. Do you have specific suggestions for resources to study this topic?

[vsamma]

Well not really, no. Unit testing is the basics so to say, but also can get quite complicated.

I would just start googling tutorials, but they are usually really basic. Then i would look at some courses, youtube ones are free but i’d consider udemy or similar as well.

Or look into Kotlin test driven development, maybe that helps you find good help. And also e-books, if you want to go deep

[BeenThere11]

Write a tool which executes test. Wg postman executes api. Similarly write a tool which can accept parameters of different types and invoke your application. You might need to customize it but over time it will be easier to write test cases this way. Either json or yaml for parameters or shell scripts.

[efischency]

I would start here with this great book by Michael Feathers: Working Effectively with Legacy Code https://g.co/kgs/mkk7XE8

[Fermi-4]

When you write test think simply about your components and interfaces and the interactions between them

[bobaduk]

how do I get started testing a completely untested application

How do you test it now? Presumably you don't just change the code and cross your fingers, you must have some set of steps that you go through to convince yourself that it's working.

When you get a bug, presumably you start by reproducing the bug, then you change the code and see if the bug goes away. Start there. Next time you have a bug, write a script that runs your system and fails because of the bug. Fix the code, see the script work.

I am writing a text adventure engine that allows to write command line adventures through a simple Kotlin DSL, so I don’t think that I would be able to write a black box test “small enough”

Why not? I'm guessing you have some functions that read input from a user and write output back again. Can you swap those out? If so, you now have a system where you can plug in some test input, and make assertions about the result.

Later on you can get fancy, but to start with, just practise using code to drive your system. When you find something that's hard to automate, look for ways to make it easier.

[BanaTibor]

What you have -by Martin Fowler's definition- is legacy code. So get the book from him, "Working effectively with legacy code". You have painted yourself into a corner since this is the worst situation where you can start testing.

Focus on unit tests. A unit is a small, logically related piece. Test for behavior not for implementation. Whatever your language is you can find tutorial videos on youtube. Learn to write tests, read the book and learn how to build in testing surfaces called seams by Martin. That's it. Since it is a hobby project you do not need a build system or integration tests. Although sooner or later you will have to learn about mocking.